Archive for the ‘Agile Practices’ Category

On Thursday the 20th of June I had the pleasure of co-presenting with Craig Smith (@smithcdau) at Agile Australia on “Visual Management: Leading with what you can see”. For the slides you can go directly to slideshare or click through the embedded contents below.

The presentation was video taped so when that is released I will update and provide a link.

Because it was a presentation on Visual Management I felt that it was quite important that visually it looked slick. I spent almost two hours a night, most nights for almost two months to get the 70-odd slides in the presentation. Some slides were cut due to the time constraints of keeping to 35 mins. Also due to time constraints we didn’t get the opportunity to cover items in more depth, in essence it was a slidefest of ideas and concepts, enough to say “hey, that’s a good idea, I could use that” but armed with the information to be able to seek out more.

To this extent I wanted to add to the slide deck some bullet points of thoughts that we didn’t have time to cover or extend further on. For those who were unable to attend I also wanted to iterate some key elements of the slides.

  • Firstly, I would like to thank a few people who made this slide deck happen. Four pictures were taken from @craigstrong and one from @caza_no7 (Ian Carroll’s) work. The Usability section of these slides was worked on with Usability expert, Matthew Hodgson @magia3e of ZenExMachima fame. Some photos were taken from the Dandelion and Driftwood cafe in Brisbane with the approval of Penny and Peter Wolff. Lastly, a number of pictures have been taken from where I am currently working at Superchoice, I am thankful to Ian Gibson for his permission to use them.
  • Slide 14, which discusses Value trees is an extension of Luke Hohmann’s Product Tree work. I have been using Value trees for a little while now to represent backlogs and am finding them more useful then a standard backlog, especially for identifying critical paths. Compared to a normal backlog they allow for recognition of the existence of dependencies and parallel processing. I am currently working on a whitepaper for these and with Luke Hohmann’s help should have it released fairly soon. The whitepaper will go into a lot more detail about what they are and how they work, so stay tuned!
  • Slide 16, the Timeline Board is sometimes considered an anti-pattern in Agile circles. It is an advanced form of a Gantt chart, but unlike a Gantt chart it is quite adaptable to real time change and exists for the whole team to have transparency and ownership of the work. I don’t use this type of board often but I do tend to use it for complex move sequences and have done so a few times. The x-axis and headers represent time. Usually this is done as a two way exponential timeline. The key milestone sits roughly 2/3 of the way across the x-axis. From that date it logarithmically goes forward in time. It also reverses logarithmicaly in time as well. For example, the headers could be 3.5 months, 2 months, 1 month, 2 weeks, 1 week, milestone -4 days, milestone – 2 days, milestone -1 day, milestone, milestone + 1 day, milestone + 2 days, milestone + 4 days, etc. Once the wall is constructed items generally don’t move. Cards do have a tendency to be added. The main thing that moves is the current time point. Anything behind it should be crossed off done, anything on it is in focus for the standup and anything in front is visibility of what is coming up.
  • Visual management isn’t just about software development. I have spent a good amount of time in my career applying it to other knowledge work areas.
  • Visual management’s audience isn’t just the team. It is about re-enforcing everything visually – for both the team, managers and customers.
  • Visual management isn’t just about a flow zone, it also incorporates many facets of other information.
  • There is a direct relationship between the level of complexity of the type of work that you are doing and the manner in which it is visually managed – generally the visual management is one degree of complexity less than the work itself. This is a new concept that has not been previously explored.
  • The application of software usability rules and how they apply to Visual Management is also a new concept that has not had a considerable depth of exploration. I am sure we will hear more from Matthew on this in the future (he felt it could have easily taken up the full 35 mins and I would tend to agree).
  • There is a misconception about the purpose of the readability of cards on the flow zone. Most think that the information needs to be retained. The key purpose of usability relating to cards is to be able to find it quickly and to be able to read it easily, not retain it. You want to be able to find it with little thought in stand ups. You want to be able to find the right card quickly when talking to the Product Owner. This is where usability and Visual Management becomes highly important. We don’t spend enough time being consistent and writing clearly when writing cards. As Lynne Cazaly beautifully mentioned in her presentation, if you don’t take the time to write neatly what someone else has told you then you are not showing respect for their thoughts that they have given you.
  • Achievements – I have mentioned them a few times on this blog. As part of this exercise of getting a slide up I somewhat simplified the generation of the tokens and the Agile Achievements playbook. If you are interested just send me a tweet and I can DM you a direct link to the content if you want to re-use it.

Lastly I want to thank Craig Smith for his help and support in doing the presentation.  I may be the Penny to his Brains (check Craig’s uploaded slide deck for the in-joke), but he is really the Will MacAvoy to my Mackenzie Mchale.

Read Full Post »

I have been probably one of the longer running candidates for being a Scrumbut user. scrumbutBack when I started Agile 11 years ago, the rulebook was slightly different – retrospectives were part of XP and not Scrum and many blended XP and Scrum effortlessly without issues. This time could be described better as doing ScrumAnd. However I also spent a lot of time experimenting, even whilst myself and my teams were in the “shu” phase.

I was an early breaker of the “must be four week Sprints” rule, trying three, two and one weekly Sprints. I eventually settled on two weekly Sprints for large (ten person) teams and weekly for smaller teams.

In smaller teams of 2-3 people I experimented with part time Product Owners – people who co-located with the team for a few hours, but were otherwise contactable at any point in time by phone.

I played with having taskcards, removing Sprint Burndowns and replacing it with stronger visual observation as a marker for Sprint goal failure risk.

Release Burn Downs became Release Burn Ups. The relative worth of a Scrum Master full time versus part time was played with.

I did all this because in those early adoption days guidelines, blogs and books were very limited. I did this because the manifesto said “Individuals and interactions over processes and tools”. I saw Scrum as a process but it did not govern or supercede the manifesto and so I played with the rules hoping to test under what conditions ‘Individuals and interactions’ was better realised and what size of Sprint lengths allowed more effective delivery of working software.

If Lean Startup had been around in those days, not only me, but many of us would have been seen to be setting hypotheses, building, measuring the effectiveness of the change in process because we certainly needed to learn what worked and what didn’t.

I believe, to an extent, that Shu-Ha-Ri is applicable, but there is no clear point to me, nor do I think there should ever be a point when experimentation is not allowed. What early adopters have learnt are the conditions and root causes why certain elements should and should not be done. I only think it appropriate that Ri experimenters delve into the unknown with their eyes wide open to the risks that the previous experimenters have found. This is where the learning can be daunting because this is where the rulebook changes into guidelines and there is a lot of information out there to sift through.

I have seen a team successfully deliver a project with no product owner using a combination of Scrum and Lean Startup. By a strict classification this would be considered Scrumbut, however it was a very successful project (probably more than many others I know because we could prove benefits realisation rapidly and the customer was ever present in the data).

I have seen successful teams have a board of Product Owners. In fact, I am a member of such a board right now. It isn’t detrimental. Prior to the beginning of each Daily Scrum, as a board of Product Owners we collectively decide on priority. The card colour denotes the Product Owner and if the team has queries they know easily who to go to for immediate feedback. Problems with process are only problems if you let them be.

I see teams follow Scrum by the letter and fail – the wrong person was the product owner, cards weren’t broken down enough, the list could be quite exhaustive.

There is always risk in experimenting, but in saying “shu” learners should only go by the rulebook, without encouraging any critical thinking, is only further encouraging the lack of movement into “ha”. When we (as trainers) teach “shu” I believe we should have a responsibility to seed “ha”. It isn’t just about “do x, y, z”, it is “x works best when …”, “x is hard to do when …”, “you may want to consider to also do w when you do x”, in essence, it is the:

  • what (approach)
  • why (purpose/intent)
  • who (is involved and to what extent, RACI is a good model for this)
  • when (how often, how does the time impact other elements) and
  • how (does it feel when it is working right versus working poorly)

We need to teach people how to think, learn and critically assess, not just give solutions. We need to stop telling them off for experimenting. If that had happened in the early days of Scrum we may have never learned of the value of shorter Sprints and of the hundreds of useful tips, techniques and tricks that we apply each day.

Scrumbut is and has always been a terrible name for deviating from the standard definition. You might argue that what I do is Scrumbut. I would say I do Agile -

For my team and my organisation, I endeavor to improve the cost-effective delivery of value to customers through the establishment of a collaborative, safe, supportive and ever positively evolving environment.

Shouldn’t that be the intent of Scrum too?

Note: This blog is a reply to the great conversation and blog by Bernd Schiffer. This is by no means a statement that I agree or disagree with Bernd, I just wanted to offer my perspective. 

Read Full Post »


Version One have released their annual State of Agile Development Survey for 2012. Co-inciding with this they also released a blog titled the ‘Top 10 Things the State of Agile Development Survey Won’t Tell You’ which I excitedly opened only to find it was a joke blog post. This was slightly disappointing as I love the effort and professionalism that Version One goes through to produce their survey and felt the blog cheapened it. I had hoped that the blog would outline the known deficiencies in the survey, but alas no. So I decided to write what I felt the  blog post may have covered if it took the topic seriously, so here it is – the Top 10 (okay maybe 13) Things the State of Agile Development Survey REALLY Won’t Tell You:

  1.  What the co-relation between those with Agile Development Practice Experience and their role as an Agile Practitioner. I suspect that the 19% of Agile Coaches/Consultants/Trainers would make up a high portion of the 25% group that have 5+ years experience (It would be very scary if it wasn’t true). 
  2. Why is it that 60% of respondents were managers/leaders or consultants – are these the only people that have time to fill in surveys?
  3. Who knows what about Agile? Asking the ‘most knowledgeable’ is a good question, but it only tells a portion of the tale. What we really need to know is the extent of knowledge that each role has in general. Whilst the Product Owner might be considered the most knowledgeable in 1% of teams, overall what is their Agile knowledge – poor, sound, good, excellent? How do we know as a community where we might need to focus improvement without knowing each role’s understanding?
  4. What is the business’s role in all this? A lot of the questions are focused at an IT layer and don’t allow answering and splitting responses based upon business versus IT – for example, are any of the Agile Champions actually from the business?
  5. Where does Lean Startup fit into the Agile Methodology used? I know of a number of teams going down this path and whilst you could argue it isn’t a methodology (nor are most of the options officially), it would be worthwhile having this approach added in.
  6. Where is ‘name your technique’ in the list of those employed? I still have no idea what ‘Integrated Dev/QA’ means – I am guessing it is eluding to a cross-functional team, but why not have the BA’s too? I don’t get Agile Games either. There is no practice or technique called Agile Games, games are a way we learn, it is a learning technique and has no direct relationship with Agile. Then we have the missing techniques – two fundamental ones beings skipped: Product Demonstrations/Showcase as part of Sprint Reviews and Backlog Refinement (formally known as Backlog Grooming). I wouldn’t put Burndown and Team-Based Estimation together either as they are two different things to me. It would be lovely to see Release vs Sprint Burndown split too.
  7. Where is ‘Cost:Benefit ratio no longer being acceptable’ as the major cause of Agile Project failures? Most Agile projects that I know get canned do so because the assumptions that were made at the start of the project no longer stack up and consequently it is no longer worthwhile to continue the project resulting in the project being cancelled. It seems to me that the ‘Leading causes of failed agile projects’ is actually talking about ‘Leading causes of failed Agile Transformations’.
  8. Where are the Kanban practices/techniques? Cycle time is there, what about limiting work in progress, pulling work, visualise and  manage flow, making policies explicit?
  9. Where are distributed teams as an organisational issue? I see this commonly as one of the biggest issues – is ‘failure to integrate people’ the same thing?
  10. How many Scrum Masters also have a ‘Project Manager’ title or responsibilities?  How many Scrum Masters also actually help the team to deliver? I would love to know the answers to these questions.
  11. How effective is the role of the Product Owner? There don’t seem to be any questions around this and I am curious as to whether Product Owners out there are answering questions in a timely manner, with the right information and how many are proxies?
  12. What is the difference in people’s minds between a Bug Tracker, a Taskboard and a Kanban board? To me they have always been one and the same. Where do portfolio management tools fit? What about retrospective tools? How many people are using a physical board vs a virtual (or both)?
  13. How many people are doing Agile versus being Agile? This is the question that I would love answered dearest of all.

So what would you like the State of Agile Development Survey tell you that it currently doesn’t?

Read Full Post »

This blog is in response to a number of requests about creating Agile games. I have spent the last two years creating a number of Agile games and whilst I certainly wouldn’t declare myself and expert next to the amazing machinations of @lukehohmann of Gamestorming I do try to make games that are fun, educational, simple and easily repeatable.

In today’s blog I want to describe the journey and thought processes that I took to build a game that I call “Kanuzzle”.

It started about two years ago when Russell Healy first introduced Kanban to me through his amazing getKanban game. Russell spent considerable time, effort and personal expense to produce this high quality, repeatable instructor toolkit. I enjoyed the game and found it quite educational but did have difficulty with the setup time and the time it took to instruct on how to play the game. Taking that aside I felt the participants in the room were able to pickup the concepts embedded within and the competition levels were high which increased the fun factor of the game.

When I returned to Australia I tried to find some interest for Russell’s game but there was a perception that the game costs were too high (for an instructor to purchase). I was personally less concerned with this as I understood the investment Russell had made, but was more concerned about the maintainability of the game once purchased.

As time went on the needs that I had for a Kanban game grew away from getKanban. I needed a game that was less software focused and was easily digestible to business specialists who were using Kanban outside of software development. I also needed a game that was quicker to kickoff and one that could be maintained an enhanced. Production costs were an issue and management ideally wanted games that costed little more than paper and pens.

So given these new constraints I went about building a new game. To overcome the production cost issue the board I created was printed on A3 and laminated. Tokens and any other artifacts went through a similar production method. This resulted in kits that cost a little more than a few dollars. Additionally I wanted to build in more “chance” to the game and brought in a design concept directly off Monopoly  building in “wildcards”. When a wildcard was landed on it represented the real life occurrence of an event that was either positive or negative to the team’s ability to deliver. The set of board steps was also fixed as opposed to getKanban’s varying cost to deliver a story. Using colour themes similar to Monopoly’s “set of hotels” I had colours that represented a number of board steps for a particular non software role.

Teams were given preset WIP limits for their board which was setup to deliberately be dysfunctional. After a few two person practices, I released my new “Kanbanopoly” game for training. The first few sessions resulted in some instructional tweaks but overall the exercise went well – I cut the exercise time down from 2 hrs to a 45 minute game. The game was run in three rounds (split among theory). The first round was the dysfunctional one. The second round the team were able to change their WIP limits as they saw fit against an overall resource constraint, in the third round they could change the WIP limits again. Team’s rarely got the WIP limit right by the second go but always did by the third.

But a few things concerned me about this variant. Firstly it was still taking too long for people to understand the instructions, especially the Cummulative Flow Diagram. Secondly people were having trouble making the leap between the game and what they were doing on an Agile basis from day to day.

So I did what any good game designer needs to be open to and totally scrapped it. My new requirement was that the game be runable within 30 minutes with similar production costs and a five minute instruction time.

What I wanted was the ability to have a massive wall and for the team to stand at the wall to do the exercise, in this respect it would be more closely aligned to what they were used to. But the problem was that they couldn’t deliver software in the classroom and I didn’t want them to do a manufacturing based game as I wanted to highlight the knowledge work element strongly. So I toyed with the idea of a game within a game and created “Kadoku”, a Kanban Sudoku variant.

Children’s Sudoku puzzles (of varying difficulty) were printed and a value was attached to them. They were then cut up and placed on the wall with a pre-setup WIP limit. Roles were given out and metrics were kept. The WIP limits were setup for success but deliberate defects were put into the puzzles to force certain roles to hit their limit and cause a flow issue. The game went fairly well as far as the lessons learnt. The instruction time was certainly reduced and the costs were even lower. Additionally it felt more familiar and transposable to the participants. But there was a serious issue. Defects took too long to resolve and the Sudoku execution itself was taking longer than expected with each puzzle taking between 8-10 minutes to get out. Simpler puzzles took too short a time being doable in under one minute.

So that variant was re-adjusted. I scrapped the Sudoku puzzles due to their complexity and went with simple kids puzzles that should be achievable by 7-10 years olds. The game was renamed to “Kanuzzle” and re-run. This game has now been running for about eight training sessions without further issues and is now considered final. The cost is about 20 pieces of colour paper and blu-tack. The setup time is about fifteen minutes to cut out the puzzles, blu-tack them and setup the physical board. The instruction time is about 3 minutes and in game running time is about 15 minutes. The design intent from a learning perspective is to get a feel of the Kanban concepts with a particular focus on WIP limits, managing flow, pulling work and handling expedites. People won’t be experts by any stretch, but they will be informed enough to now give it a try and self-adjust.

So lets take a look now at the things that you need to consider when building your own Agile game:

  1. Who is the audience? What will they know? What won’t they know? What terms may be unfamiliar for them?
  2. How much time do they have to play a game?
  3. How much time do you have to run a game in the context of the rest of the training?
  4. How much time will it take for you to preset/reset the game? Is this something that you can afford?
  5. How much time will it take you to instruct in the game? Is this something that can fit into yours and your participants training time?
  6. How much time does the game and any post-retrospective debrief take? Is this something that you can fit into your and your participants training time?
  7. How much do the physical gaming materials cost? Are they re-usable?
  8. Is the game maintainable? Can you adjust it and re-run with adjustment costs being minimal?
  9. What key messages do you want to get across? What agile practice(s), principles or values are you trying to re-enforce?
  10. What would be nice to get across if you had time?
  11. Can participants easily relate this to their work?

Also keep in mind general game building considerations that all games should adhere to (for more information checkout my Gamification and Agile slideshow):

  1. There needs to be clear and defined goals or outcomes that have to be achieved
  2. There must be a set of rules in place to limit how you go about achieving that goal
  3. The environment must provide feedback to tell participants how they are going or whether the game is ended
  4. They must be voluntary

In the case of Kanuzzle the answers to these last four questions are:

  1. Achieve the most value. Two teams compete against each other. By default the puzzles are ordered according to sequence and not value, part of the design intent is to get them to spot that the backlog is not value prioritised and then to re-adjust it.
  2. Limits are enforced by WIP limits on the board and through rules for handling expedites and roles for the game. Roles are loosely set so ideally by the end of the game no one cares about their role, they are just focused on the flow. Additionally by forcing an error into the flow early it forces the team to deal with flow issues and understand what it feels like and the impacts that it has.
  3. Feedback is provided via timing each puzzle and through provision of graph tracking. Instructors also give feedback on game end time.
  4. They must want to learn and participate in training

Read Full Post »

As part of my back to basics series I wanted to spend some time on the topic of Retrospectives, otherwise known as Introspection or Reflective Improvement sessions.

If the Stand-up is the bread, then the Retrospective is the butter. It is simply just one of the most fundamental elements of doing/being Agile there is. Alike Stand-ups, they are just as easy to be ineffective.

At its most basic process this is how to run a retrospective:

  1. Get the core team together
  2. Give the core team 10 minutes to brain-storm their thoughts on how the last Sprint/<insert cadence cycle> went in terms of:
    • What is working well?
    • What to do differently?
    • What still puzzles us?
  3. Group like thoughts together
  4. Choose items to focus on and address
  5. Make actions

Let’s break these items down a bit more:

Get the core team together

It doesn’t have to be in a meeting room. It can be in the pub or in a park. In fact, the team don’t even physically have to be together – you can do retrospectives virtually using a tool like LinoIt. What is important here is that the team needs to feel safe to speak freely and that there is an environment where there are no elephants on the room. If you have a Project Manager or a Product Owner that will not be conducive to such an environment then you have a bigger problem here – re-focus the  retro on getting this fixed!

Brainstorm for 10 mintues

There are five points I want to make on this sub-activity:

  1. The duration to reflect on is not important, but framing and frequency is. Retrospecting once every three months is not being Agile. The more frequent you can do this activity the better. Keep in mind, as you increase the frequency you may need to spend less time doing this activity – ie if you choose to retrospect each day then it could be a ten minute activity.
  2. Ensure the brain-stormed items are put on a single post-it note and are clearly legible so that you can take a photo of it later. There is nothing more annoying then spending time capturing/documenting the retrospective. Take a photo of the outcomes and stick the photo on your team’s wiki.
  3. I sometimes like to add a fourth item, “Lessons learned”. I believe that celebrating what we have learnt together as a group is very powerful and enables both sharing of information and a recognition that we aren’t perfect and it is a good thing to always learn.
  4. Sometimes people like the second question to be phrased as a negative and not solution focused question – ie “What isn’t working well?” vs “What to do differently?”. The benefits of the “What isn’t working well” approach is that it doesn’t assume root cause and leads to potentially better solution analysis later within the retrospective. The downside is that for the people that aren’t good with dealing with criticisms this can sometimes be confronting. I don’t think it matters which you choose, just be aware of the risks given the wording and work out which format better suits your team.
  5. The focus on the reflection is not what was produced but how the team worked together to deliver.

Group like thoughts together (affinity mapping)

Notice that I didn’t say how to do this? That is because your mileage may vary based upon your approach. The Scrum Master can do this once everyone has written their thoughts, or the core team can do it themselves – either one at a time or as a collective. You can read them out or get the team to quietly read it themselves, the options are really endless. My personal preference is to get the core team to affinity map themselves and then to verbally skim through the non grouped items and spend more time on the strongly grouped themes. Items under “What still puzzles us” should be answerable on the spot or may become a focus area.

Choose items to focus on and address

Usually I would choose the strongly grouped themes but there is a risk that you miss something important that can significantly improve your ability to deliver as a team. What is important is that the items you choose to focus on are the ones that will result in marked improvements for how the team will work together.

It is a rookie error to focus on ten things within a single retrospective. If you have two weekly Sprints, you ideally don’t want to focus on any thing more than three (five at absolute tops) actions. This is because you want to ensure that you are making changes and if you have too many actions then nothing will change and then you will loose all support from the team for doing this practice in the future.

Who makes the suggestions of the changes? The core team does. It shouldn’t be the Scrum Master who is imposing change on the team, it should be the team embracing an environment of continuous evolutionary improvement.

Make actions

So along with only having three actions you want to ensure that these actions address the root cause of the problem (ie you are not solving the wrong problem), that the actions have clear owners, dates (if possible) and value.

The best actions I have ever seen out of a retrospective are ones that the team writes as stories and then feeds the stories back into the release or sprint backlog – ie they get treated like everything else. Because they are treated like everything else they get a priority and estimate which means that they have to have value as agreed by the whole team in order to work on them in the current Sprint.

If you aren’t going to write them up as stories and add them to your backlog(s) then make sure the first step you do in your subsequent retrospectives is to review previous actions. It is a smell when actions get carried over from retrospective to retrospective – it is symptomatic of items that weren’t perceived as important or that the team feel that continuous improvement is not important.


Software development isn’t simple. The only way that we can improve in the complexity that we are working with on a day to day basis is the reflect and adapt. Sprint Planning and Sprint Reviews are the way in which we reflect and adapt the work we are doing. Retrospectives are the way we reflect and adapt how we are doing our work.

Read Full Post »

Can them what you will – Daily Scrum, a Huddle or a Stand-up, but whatever you call it a Stand-up is one of the simplest Agile (and arguably knowledge and service management) practices  out there. Three questions are answered by the “core team”:

  • What I’ve done since we last met…
  • What I plan on doing till we next meet…
  • What is impeding me or may soon…

Simple right? Wrong!

These very simplistic set of steps have led many to believe that the key purpose of a Stand-up is as a progress report. To set the record straight:

The key purpose of a Stand-up is the opportunity to collaborate, share and support each other in the delivery of valuable outcomes.

For those that may not have heard of the above interpretation of a Stand-up’s purpose then let’s take the opportunity to understand it further. As each person answers the three questions what the rest of the team should be doing is listening and wondering to themselves the following questions:

  • How will this impact me?
  • How will this help me?
  • Will my work impact them?
  • Can I help them?
  • Can I potentially learn from something they are doing?
  • Can something I’ve done in the past be useful so that they can learn from it or re-use it?

If the answer is ‘Yes!’ to any of these questions then the team member should pipe up and respond. An effective Stand-up isn’t just the team turning up on time and answering the three questions – it is where teams work together to deliver and reach the delivery goals whilst always upholding the values and principles.

Another common Stand-up myth is that they should be 100% valuable to 100% of the core team 100% of the time. This is simply not the case. As we now understand what an effective Stand-up is you will be lucky to find these opportunities consistently and rarely more than three times in a single Stand-up. In fact, you might go through a few Stand-ups before such an opportunity arises – these uncommon instances of “I’d love to learn more about how to do that, care we pair?”, or “I’ve had a similar problem on my last project let me send through to you what we did”, or “I know that person well, let me talk to them and try to push the impediment out” are what make good Stand-ups.

We’ve all heard of tips like taking difficult conversations offline, ensuring everyone can be heard and timeboxing each person to no more than 2 minutes but here are a few tips that I would additionally recommend to make Stand-ups a little more effective:

  1. Touch your cards. If you don’t do this as you are talking the team is mentally trying to match the first sentence of what you said to the Story Wall. As they are doing that mental matching they are no longer listening to what you saying which consequently invalidates the value of the Stand-up.
  2. Take 2-3 mins before the Stand-up to jot down what you want to remark on. If you don’t do this you dramatically increase the likelihood that you are spending time, whilst others are talking, concentrating on what you are about to say. You need to be in the moment of what the team are saying, not what you are about to do.
  3. Jot down any issues or risks remarked on. Ensure that they are visibly attached to stories with clear owners and status/actions.
  4. Hold each other accountable if a team member is talking about work that isn’t reflected on the Story Wall – get the story written up and prioritised against everything else on the go.

Note: Astute Agilistas will notice the subtle changes in the core three questions. Primarily this is because I have seen effective Stand-ups that whilst they are regular and frequent shift away from the activity being daily. Additionally I like to tack on the “or may soon” to the last question because whilst the question focuses on issues the “may soon” is a focus on possible risks.

Read Full Post »

Jvonvoss at Minds.coremedia.com recently did a very interesting blog – A World without Burndowns: The Unified Taskboard. It was an interesting concept – use your done column to replace your burn down chart.

Normally a taskboard will look like this:


The done column is just a list of everything that the team has achieved. Colour may be used to denote expedites.

Using Jvonvoss’s advice a standard Iteration Wall would have the Done column split into each day of the Sprint:


In this example, whilst on day 9 we know with certainty that we wont get through all the cards within the next two days as we have been consistently achieving 2 cards per day.


In the above example knowing whether we would finish all the cards by the end of the Sprint would be harder to work out – but the interesting reason is why. We can very easily see that the daily throughput is spiking up and down a lot. There is a constraint in the system. You would likely be able to see this as well in a Burn Down chart but visually this would pop more for visitors or managers that walk by.

Using Kanban, similar concepts of visualisation within the Done column can be used to track cycle time. In the example above we can see some outliers, but a majority of the cards are being done within three days and expedites are getting done on the same day. Again this won’t necessarily replace other graphs but the transparency is more apparent.



Lastly, how could you use a wall to track demand over time within the service industry? Cafes commonly print orders on dockets and add them to a backlog of beverages to produce. As the Barista becomes available they take the next priority item in the backlog and begins working on this. Imagine that when done putting the docket up on the wall by the hour that it came through – what would this enable a cafe owner to do? You can see from the above image that the peak time is 8-9 – you would make sure the majority of staff were on at this time, between 12 and 2 you would likely rotate lunch breaks and you might choose to close down earlier than 6 given how few the orders are in that time slot.

What other ways could you think of using the Done column?

Read Full Post »

  1. If a story is a promise for a conversation then… an estimate is a promise to potentially get it wrong
  2. If a story is a promise for a conversation then… a retrospective is a promise to follow through on agreed to actions
  3. If a story is a promise for a conversation then… a vision is a promise to make some SMART goals and then re-evaluate if it is achievable
  4. If a story is a promise for a conversation then… an epic is a promise to break it down
  5. If a story is a promise for a conversation then… a minimal viable product is a promise to deliver the smallest amount possible to learn
  6. If a story is a promise for a conversation then… an Iteration is a promise to not introduce change within it
  7. If a story is a promise for a conversation then… a minimal marketable feature is a promise to deliver value as early as possible
  8. If a story is a promise for a conversation then…  you really shouldn’t be writing that 20+ page specification – get up, walk over to the team and start having a conversation!

Read Full Post »

I have been pondering lately what the purpose of a Scrum Master or Iteration Manager is.

Many believe that it is a 100% full time role. Some are even concerned that there are formal positions springing up for this role.

Here is my stance (and work in progress model) on the role:

The purpose of the Scrum Master role is to create a self autonomous team through the usage of Agile.

  1. It should never be considered a 100% full time role.
  2. It is a transitory role – there to enable a change in the team.
  3. The change is a change from an environment of Command and Control to an environment of autonomy and empowerment.
  4. The goal is to deliver value to customers frequently and regularly through creation of this environment. The goal is not to have a Scrum Master job for life.
  5. They do this through a series of steps.
  6. These steps are based on Situation Leadership with some tweaking:
    • Directive – The Scrum Master is telling the team what to do and how to do it. This is sometimes common when the team is new to Scrum/Agile and are still learning the rulebook.
    • Facilitative and Advisory – The Scrum Master facilitates cadence activities and advises the team on possible options but is not the final say.
    • Cross Facilitative – The Scrum Master engenders an environment where other team members are starting to facilitate the cadence activities. At this stage the Scrum Master is no longer rounding up everyone for the Daily Standups, instead the team self form and remind each other.
    • Coaching and support – The Scrum Master is only there to course correct and even then only does it through team reflection. They don’t advise on options, instead they engender an atmosphere where the team can come up with their own solutions.
    • Double loop learning – The Scrum Master is ready to hand over the team to itself. The team reflect not only on how they are working together but why they are doing practices in a particular way. It is creating an atmosphere of learning transcendence.

So what, you may ask, does a Scrum Master do as their time with the team whittles down? They do what any good team member in a Scrum team should do – they deliver User Stories!

Read Full Post »

Last week Assembla posted the 7 things they hate about Agile.  Here is my take on their seven things I hate about people that hate Agile:

1) My cultural norms are not your cultural norms

Apparently according to Assembla everyone that does Agile is old.  Damn I have been doing Agile since I was 27. Apparently that means I am old. I hate that cultural norms are flouted as if they apply worldwide. In the southern hemisphere those following Agile are more likely to be under 40 than over 40.

2) see point 1

Assembla says that Agile is stagnated. Again, just because it has in your country doesn’t mean it is a worldwide norm (see last blog). I agree there is a risk that people want to do and not be Agile, but that has nothing to do with stagnation. I have argued many times on this blog that Scrum is stagnant, I won’t dispute that, but Agile !=Scrum. What Assembla is ultimately saying is that people aren’t learning of other approaches other than Scrum. Is it because they don’t want to, because they see little value in anything else or is it ignorance? I don’t know the answer, maybe Assembla does. When I think of this point it makes me ponder on why we replaced Waterfall with Agile in the first place – was it not because Waterfall failed to evolve and address the problem we were having. Where is it written that Agile must or cannot evolve? We are the community. We are the ones that encourage it’s evolution or not.

3) People that don’t value values

Assembla says that the values in the manifesto aren’t applicable. The examples that they provided were all of manufacturing or command and control environments. Last time I looked Agile was being used for knowledge work not manufacturing. Also Agile methods were used in WWII – in war rooms – where knowledge and innovation were critical. I agree that shared goals are important. I agree that if you can deliver your work and not have to talk to a single person (or even a customer) then values are not important, but I don’t know of anyone in software development that can get away with that excuse these days. You have to have values and goals when doing knowledge work. I am not saying the manifesto is perfect, hell I am enjoying the MoreAgile manifesto these days, but that doesn’t mean all values are useless.

4) People who don’t understand how complex it is to change command and control behavioural patterns

Assembla says that they hate the Scrum Master role and believe that SMs don’t do anything and need to get a real job. As someone that spends a lot of their time trying to re-wire behaviour away from command and control to enable environments where teams are empowered and autonomous I find this frankly insulting. We are taught to respect elders as children, to not talk back to authoritarian figures. Throughout our childhood and schooling we are constantly re-enforced with command and control messaging. And yet we know through many studies that empowered and autonomous teams are more productive and innovative. The Scrum Master is there to break down the old patterns and enable the team to do their job without interruptions. This isn’t something that happens overnight, it takes months of re-enforcement for neurological pathways to re-assert themselves to be the prime pathway. Does this mean that a Scrum Master role is full time – no! They will be helping to deliver when they have free time. They are just a normal in the person in the team who has chosen to step up.

5) People who think that Agile means you have to estimate/People who think that Agile means you don’t have to estimate

Assembla says… actually I am not sure if they are for or against estimating from their comments. Estimation really depends on the environment that you are in, the governance and financial models applied to get work started. Ideally work would be incrementally funded. Ideally all work would be broken down into roughly the same size. In this ideal Agile world estimation is not required (assuming you understand your cycle time or throughput of work items over a defined duration). If you don’t live in this ideal world you might need to estimate – at best a rough idea of the size of the project based upon relativity to other similar sized projects, at worst so you know your velocity if using Iterations.

6) People who assume a practice is 100% applicable 100% of the time and that common sense has no place

Assembla says that pairing all the time is not valuable and just to pair reviews. For me pairing for reviews is worst case scenario, it is a lag identification of problems. Would I recommend pairing all of the time – hell no! But if it was complicated business logic or a new architectural framework being implemented then I would recommend upfront pairing.  Pairing is about quality, reducing rework, cross skilling and engagement.

7) People that think just because it is hard that you shouldn’t strive for it

Assembla goes into some points about Scrum and it’s poorly formed ideas. The first is about co-location. I am not sure exactly what problem Assembla has with being in a work environment that is fun (what people don’t enjoy an odd game of Foosball?!?). I agree that co-location is much harder to do these days, but does that mean you shouldn’t strive for it? There are mixed benefits in this field – co-location provides reduced costs to communication (Thomas Allen curve), but conversely co-location decreases engagement (by 0.2% assuming you are instead working from home, still the figure is fairly negligible).

The second point Assembla makes on this is that cross functional teams are unachievable. In large organisations maybe, smaller ones less so, it depends on your environment. Again it doesn’t mean you shouldn’t strive for it. A cross functional team in the long term is more productive. The purpose of a cross functional team isn’t to reserve talent (where did that one come from?).

The third point Assembla makes is in regards to capacity changing weekly. Discipline is hard. Yes unplanned things happen but onboarding/offboarding project team members every week is a severely dysfunctional Agile team and if this is the norm your organisation has serious problems regardless of Agile. This is why most Agile environments are shifting to product rather than project teams – that way the capacity and capability is always there.

The fourth point Assembla makes is that bugs will come up as you work and these impact your ability to deliver to a plan. Again discipline is hard. If you choose to use iterations, then understand your metrics of how much this is impacting you and add it into your planning process. Alternatively use an iterationless method and allow production defects to be handled as expedites. Or even better build quality in and don’t get bugs in production.


If Assembla is changing its developers every week, has bugs as a frequent occurrence found within production environments (hinting at  lack of automated testing coverage and quality testing), has developers incapable of widening their capabilities, teams that are stagnant, old, without values and breathing each day in an innovationless command and control environment I am really not sure that I would give them my business.

And Assembla – if your response to this conclusion is “we don’t use Agile” then I’ll add my #8 hate:

8) People that hate on Agile who don’t even do it.

Read Full Post »

Older Posts »


Get every new post delivered to your Inbox.

Join 920 other followers