Feeds:
Posts
Comments

Archive for the ‘Kanban’ Category

For those that have been on the Agile journey for a while this post will hopefully come as no surprise, but if you are fairly new on the journey I wanted to take the opportunity to clarify what I feel is a common misconception about Agile.

In the early days of Agile we made it a Waterfall versus Agile war. It was one or the other. One over the other. This when ‘x’, that when ‘y’. We spent time explaining the pitfalls of Waterfall and why Agile was better. Maybe that was right at the time. Maybe we did it because we didn’t know better. Whatever the reason the concept of an Agile transformation being replace old process with Agile has stuck around.

But I don’t think that the point of an Agile transformation is a process shift.

I have a suspicion that where Agile has succeeded, it did so not because of the process shift but because of something else – a thinking model shift.

What was the problem that we were trying to fix with Agile? Was it really the process or the mindsets that people had? The manifesto articulates it somewhat – “Individuals and interactions over processes and tools”. It isn’t that process isn’t important it is that the thinking model that process should always trump was broken and that some slack should be given to humans who may have felt that the process didn’t make sense given the complexity of the situation.

Somehow, despite the manifesto, when we began Agile transformations we ignored the “over processes and tools” somewhere along the line. Frameworks and certifications are springing up everywhere – SAFe, Kanban certification, Disciplined Agile Certification, ICAgile, Scrum, etc. How many of these are focused on process and technique over the ability to shift thinking models?

What I feel Agile should be is different now than it once was. What I feel the manifesto should be now, is more along the lines of:

We are uncovering better ways of working together as human beings to deliver value  to shareholders and delight to customers whilst at the same time improving the engagement of employees. Through this we have come to value:

  1. Synergistic thinking over mechanistic/analytic thinking
  2. Servant and situational leadership over command and control management (alt: unleashed human potential over apathetic or toxic environments)
  3. Full value stream optimization over sub process optimization
  4. Process experimentation over defined process
  5. Aggressive feedback controls over prolonged feedback controls
  6. Stimulated neurological pathways over stagnant neurological pathways (alt: learning culture over sole focus on delivery culture)
  7. Breathing space to enable creativity and innovation over 100%(+) utilization

That is to say whilst the things on the right are our current behaviours, we want to shift to the items on the left

 

Read Full Post »

purposeSometimes there are moment in life when like a bolt out of the sky you have a major self realisation. I had one of those moments recently when I realised that for a majority of my coaching life I have been pushed and prodded by my leaders/managers to behave as a Purpose Driven Agile Coach.

What is a Purpose Driven Agile Coach?

It is a coach that is asked/told that when they implement Agile that there needs to be a plan to improve capability. Targets are set and tracked weekly. An example could be, “Improve stand-ups within the month”, it is still very open ended but the practice it is linked to and the time frame is set.

I would imagine that this is quite common in organisations with low Agile maturity and very strong old school management mentality. In these cases, organisations want to predict and understand the value that Agile Coaching provides. Often this is linked to definable metrics, before and after of Agile capability in teams, but I often felt that this capability was shallow. I would be pulled and moved onto another team before I had a chance to really embed the change and ensure that behaviours didn’t regress. I was often only given the time to teach the ‘shu’ basics and never the time to allow for trancendence to ‘ha’ (and certainly not ‘ri’).

But lately I have been less pressure bound from a coaching perspective (I still have pressure, it is just different). This release of pressure to not plan has resulted in me using a different model – Opportunistic Agile Coaching.

What is an Opportunistic Agile Coach? 

It is a coach that only course corrects or teaches based upon the moment, taking into account both team and individuals mental model readiness, change value and change fatigue. Let’s break this statement down some more.

Mental model readiness is about whether the team or individual is in an intellectual state of readiness to receive the coaching advise/support/inception reflection idea. For example, I might personally believe that the benefits of estimation are limited, but the team may have given the concept little thought. Mental model readiness is about whether they have been asking the same questions themselves or whether I have introduced the inception reflection idea. I say ‘inception reflection idea’ because it really is like the movie Inception – you want to seed the idea or consideration in the team as to whether the practice is worthwhile or not and give them time to reflect on it.

Change fatigue should be fairly simple – how much change is the team or individual currently dealing with? If they are completely new to Agile or are mentally still coming to grips with some concepts of Agile then I am less inclined to make drastic changes. For example, if they are familiar with Scrum terms such as PBI and Sprints, where as I am more comfortable with saying Stories and Iterations, I will just go with their flow and not introduce name conflicts for the sake of it.

Change value is about whether the team or individual will get much (if any) improvements from the change. By improvements I mean faster client feedback, improved customer value, improved personal engagement, etc.

Regardless of which Agile Coaching method, I have always started by mentally creating my own backlog. It is easy for me to see what practices need to be improved and where. Sometimes if there are a lot of issues or the complexity is significant I will write it down as a real backlog and estimate it. To some extent, I have always done coaching with opportunistic elements – ie I gauge priority by change value and do take into account mental model readiness, but when there is no set plan, then it is really very liberating.

As a problem or situation crops up I can assess it against where the item fits in my mental backlog. If it was bubbling up closer to the top then I will use the opportunity there and then to address it. I might let certain opportunities pass as they are still very low on the list, but what might have been tackled four weeks later in a planned approach is addressed on the spot, with immediate context and relevance.

Relevance to revolution vs evolution in Agile models

My realisation of the existance of two Agile Coaching approaches, purpose vs opportunistic, made me then immediately think of the revolution versus evolutionary debate in the Agile community. A purpose based approach is more closely aligned with a revolutionary approach where mass transformation is expected/desired and cookie cutter conformance is achievable due to standardised but complicated teams. A opportunistic approach is more closely aligned with a evolutionary approach where incremental change is made based on team readiness and self-realisation – there is no cookie cutter conformance and there is a realisation that there is no such thing as standard teams, or that teams that are dealing with complex problems.

Conclusion

I know we would all like to think of ourselves as opportunistic coaches, but how many of you are really doing purpose based Agile Coaching and is there a right/wrong way?

Read Full Post »

monkey

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 »

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 »

I had a great meal last week. It was more like a feast really. It started lunchtime on Wednesday the 20th and went all the way through to just past lunchtime on Saturday the 23rd. I am referring to the mystically labelled #klrat or Kanban Leadership Retreat held in Mayrhofen, Austria.

Going into the event I am not quite sure exactly what I was going to expect and get out of attending. I knew that I would greatly appreciate the networking and socialisation with similar practisioners, trainers and transformationalists (and I was in no way disappointed, all expectations here were well and truly exceeded), but aside from that I went into the event thinking that there was little that I wouldn’t be aware of or know.

Boy was I wrong. The amount of talk specifically on Kanban was probably only about 30% (subjective). Agile took up about the other 30% and the other 40% were models and concepts – some of which I knew but many that I had heard of and were re-inforced (eg Cynefin, Right-Shifting, Situational Leadership, etc) but a lot I had only briefly ever touched on or never heard of.

So what I primarily wanted to do with this post – is tell you about everything that I either heard about and want to investigate/read further or resonated significantly with me. These were my takeaways:

“Kanban is like Buddhism. You are quite welcome to keep your other religions when you become a Buddhist.” David J Anderson.

Facilitated by Liz Keogh @lunivore

In addition to having a lot to look over I also wanted to go into the experience with an open mind that some of my beliefs are wrong and should be fundamentally challenged. These are the quotes from people that made me ponder for many hours after where I could have it wrong:

  • “If you start with a presumption of innocence you will get further” (with regards to change). Liz Keogh eg. “I observed you doing x, does that match your recollection of events?”
  • “How can we get <this> outcome for you?” Liz Keogh
  • “We assume as change agents that everyone wants quick results” Torbjörn (@drunkcod)
  • “One of the worst things we can do (as coaches) is make walls for teams” (either @drunkcod or @jaspersonnevelt, both of these gentlemen were letting the quotes fly freely)
  • Companies are shifting more and more away from jobs for life. Loyalty doesn’t exist anymore (sound familiar?). We can expect a dramatic shift to more community based loyalty and involvement within. “A lot of people I would call colleagues aren’t in the same organisation, they are in this community”. This will lead to a framework of 70:20:10 shifting even further into the social area of learning (eg to 65:30:5), twitter (and even the unconference itself) is a classic example of this growing.
  • People have to want to change.
  • Instead of ‘Minimum Viable Product’ think of it as a ‘Minimum Viable Experiment’
  • and the many amazing conversations with Lowell Lindstrom @lowelllindstrom who enlightened me to why Scrum is a rulebook again and why Agile should never be all encompassing or swallow up general professional capability.

I want to take this opportunity to thank David Anderson, Katrin Dietze (@thisismui) and Sigi for all of your hard work in making this such a successful event.

Read Full Post »

It all started with a problem with the way we were doing software development. Projects took years with “phases” such as Requirements, Design, Development and System Testing taking six months each. We used to create thud factors where our value was determined by how much the table shook as we laid down our documents that we laboured over for hours on end. There had to be a better way, and as it turns out, there was: Agile.

People often talk about how Agile has failed or not solved anything. But even if Agile had not come along the world of software development would have had to have changed. In a market when speed is important, in a market where delighting the customer has a direct impact on sales, we would have had no other choice then to look at solutions such as continuous deployment, automation and suped-up customer collaboration.

But Agile didn’t solve everything. Some teams found it incredibly draining to apply it to their environment. They described it as trying to fit a square peg into a round hole. They were teams that had large backlogs of work not a “project”, they were not date driven and sometimes they had specialisation. In essence they were operational or maintenance teams. So they sought other approaches that would suit their needs, methods that were more supple to their workflow but still had elements of agility. And they found Kanban.

There are still teams doing work who haven’t had their problems solved. These teams have a different problem again. They have a set date for an outcome to be delivered, high specialisation or domain specific knowledge and variable demand based upon the stage and breakdown of the work.  This doesn’t normally happen in small organisations. This is a problem for large to massive enterprises. Neither textbook Agile nor textbook Kanban fit well in these teams. Primarily this is due to the fact that a stable velocity or lead time cannot be achieved – simply put, the team is too variable. The variability of the team changes based upon the story being delivered.

Let’s take a look at the work for such a team:

  1. Feature A
    Story 1, Priority 8, RPSI (P – Fred Flintstone, S – Barney Rubble, Bam Bam, Ken, R – Bam Bam, I – The boss)
    Story 2, Priority 6, RPSI (P – Fred Flintstone, S – Wilma Flintstone, Betty Rubble, R -,  I – The boss)
    Story 3, Priority 1, RPSI (P – Fred Flintstone, S – , R -, I – Betty Rubble)
  2. Feature B
    Story 4, Priority 2, RPSI (P – Barbie, S – Ken, R – Ken, I – Matel)
    Story 5, Priority 3, RPSI (P – Barbie, S -, R – Ken, I – )
    Story 6, Priority 5 (P – Ken, S – Fred Flintstone, Bam Bam, R – Bam Bam, I – )
    Story 7, Priority 9 (P – Barbie, S -, R – Barbie, I -)
  3. Feature C
    Story 8, Priority 4, RPSI (P – Ken, S – Betty Rubble, R – Betty Rubble, I – Bedrock)
    Story 9, Priority 7, RPSI (P – George Jetson, S – Barbie, Betty Rubble, R – The Thunderbirds, I – )
  4. etc etc

You will notice that there is an attribute attributed to each story that normally isn’t there for Agile work. This is a modified version of a RACI and RAPSI, which is a roles model for processes and activities and a role model for deliverables respectively. The example above predominantely uses the RAPSI model, but some work would benefit from the RACI more. A RAPSI normally stands for “Reviewers”, “Approvers”, “Providers”, “Supporters” and “Informed”. The provider is really the owner of the story, the person accountable. Supporters help the generation by answering questions and providing input. Informed receive the output but for information purposes; sometimes people believe this means they are the end consumers but that is not the intent. The “Approver” has been taken out as it isn’t the intent of an agile process to have heavy approvals – the assumption is reviewed is enough.

Some stories don’t have corresponding names against the roles. That is fine as long as consideration has gone into whether such a person(s) exists and why this story doesn’t require such roles.

It could be argued – when is a team no longer a team? But despite this the work needs to be done and the team does need to collaborate – not on a daily basis possibly, but on a story basis.

Trying to plan for this variability of when certain people are needed in the team could be potentially chaotic. If we tried to work in priority order and ensured that all of the cards were roughly the same size how could we potentially plan out resource needs in advance? The simplest solution is to give a weighting to the RPSI elements. As an example Providers would be ‘4’, Reviewers would be ‘1’, Supporters would be ‘2’ and Informed is ‘0’. Lets look at the resource usage for the first five cards in priority:

  • Fred Flintstone 6
  • Barney Rubble 0
  • Wilma Flintstone 0
  • Betty Rubble 3
  • Barbie 8
  • Ken 12
  • Bam Bam 3
  • The Thunderbirds 0
  • The boss 0
  • Matel 0
  • Bedrock 0

So Ken is very heavily focussed at the start of the work, despite being the provider of only two cards. We are hardly using Betty, and not using Barney or Wilma at all. If the team takes the assumption that there is a maximum threshold for a person and that value is 12 for any person for a week then this week is full and no more should be pushed into the weekly plan. So what does this mean for the under-utilised team members? Surely they would go back to doing their other work until the project is ready to pull them?

What has this method done – it has taken into consideration the constraints of the team, the constraints of the story and created a framework to plan week by week without ever having to estimate. It considers the maximum limit of the team and the variability of how they may be involved in a day to day basis. What it doesn’t do too well is drive for efficiency and assumes that lighter or dead time is spent elsewhere.

This approach could be called “VSM” or Variable Systems Method, but someone else took that acronym. It is a different method for a different problem. The Variable Resource Method.

Disclaimer: This is not a method I have been using on software teams, but it is a method I have had to entertain for Agile in the Business. Your weakest link is your busiest resource.

Read Full Post »

Over the weeks we have had considerable deep dives into Scrum and how it has evolved over the last ten years. The first week we looked it at a high level, then we had a look at the roles, ceremonies and artifacts.

Now we have the opportunity to see how it has not evolved. It is important to note that Scrum is a Project Management Method (purists might argue it is a framework). It is not, nor has it ever said it was a methodology. Nor has never said it was a method for improving the capabilities of software developers.

It was created and in use prior to the name “Agile” ever being associated with it. It was one of the many “light-weight” methods that were contending for attention away from Waterfall. When Jeff Sutherland, Ken Schwaber and Mike Beedle joined fourteen other signatories in Salt Lake City there was little that they could agree with other than the manifesto. Despite this, the manifesto propelled the light-weight methods into the limelight and was a vocal enabler for a new future.

Some IT people have never experienced Waterfall or even RUP. They don’t know what it was like in the old days. Maybe the problems were due to commercial issues rather than method issues, but even with all the hoopla over Agile or Scrum not working or dead I remember what it was like in those days and we are certainly better off for those signatories creating the manifesto and propelling our focus.

But like Waterfall not being a comprehensive methodology Scrum certainly is not. This means that when people are trying to apply Scrum they are only applying a single piece of the puzzle. Many believe that Scrum = Agile. Those that know better are left in a minefield of information overload having to gleam which other methods they need to apply and how it will correlate with their existing process. In essence, Agile is like a toolbox. There are many tools that you need to use to fix the problems you have. Some tools won’t be the right tools for your problem. Arguably if you have no problems then don’t use any tools… as long as you aren’t fighting Ostrich syndrome.

Scrum has just a few of these tools. Over the last ten years it is evolved minutely to the problems and the new tools that are required in our box. Evolution did include the addition of retrospectives, intellectual property that was owned elsewhere. Even the origin of Daily Stand-ups was IP from elsewhere. Nothing is new, concepts are just re-played and re-packaged. Some might argue that the reason Scrum did not evolve was primarily due to IP concerns. But maybe, if the upper echalon of Scrum had listened to the voices of the community they would have had the opportunity to incorporate these new ideas and thoughts.

So what has evolved in the Agile community over the last ten years that Scrum has ignored:

  • How to apply Scrum to teams that have multiple customers that additionally have to support (ie potentially hotfix) production environments
  • How to identify constraints in the flow of the system
  • How to ensure that the work the Product Owner comes up with is the right work
  • How to incorporate feedback loops in order to verify benefits realisation
  • Stories, Epics, MMFs, MVPs, Themes, Parking Lots/Feature Progress Charts, BDD
  • How to estimate (eg planning poker)
  • How to understand what is more important – scope, cost, time or quality? eg Rob Thomsett’s Success Sliders
  • How to create a backlog in the first place
  • Who has the money and what visibility should they have?
  • Mastery practices, arguably owned by XP, eg pair programming, TDD, Continuous Integration; or even simply where design and architecture fits in
  • Where management, leaders, Project Managers and Business Analysts fit in
  • Where business cases, governance, procurement and commercial reality fits in
  • What tools to use to support the cultural change that goes along with implementing Scrum
  • How to create effective walls and other visualisation techniques
  • How to deal with the distribution problem (this is huge and only going to get worse)
  • How to apply it to anything other than software development
  • How to scale it to large organisations where team members are working on multiple projects at once or significant dependencies exist
  • How to get any form of metrics on effectiveness of the change including temperature checks of people’s comfort levels of the change
  • Incorporating all elements of the project and not just thinking of software development only – ie communications, training, process re-engineering

Maybe I am just asking too much. Methodologies seem to be dead, disparate ideas spread everywhere seem to be the norm. If complex systems are so hard why are we making it harder as a community to find the answers?

Read Full Post »

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In this post, part 2 of 5, we look at the roles and how they have adapted, or not, over the years.

There are three defined roles for Scrum – the Product Owner, the Scrum Master and the Team. The links from 2003 for roles were dead but I think we can safely assume there were three roles back then.

Product Owner

In the 2007 pdf we have the Product Owner defined as:

The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting product. The Product Owner achieves initial and on-going funding for the project by creating the project’s initial overall requirements, return on investment objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration. The Product Owner is responsible for the success of the product.

In both March 2007 and March 2009 the Product Owner definition was:

The Product Owner has the following responsibilities.

  • Define the features of the product;

  • Decide on release date and content;

  • Be responsible for the profitability of the product (ROI);

  • Prioritize features according to market value;

  • Adjust features and priority every 30 days, as needed; and

  • Accept or reject work results.

The product owner is responsible for the first of the three Scrum ceremonies: Scrum Planning.

Within scrum.org the definition is now:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

 The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says. 

The ScrumAlliance definition of the moment is sparse with:

Product owner: responsible for the business value of the project 

Product Owner results and opinion

  • Aside from the ScrumAlliance’s less then detailed overview there can easily be seen a small transition of improvement of understanding of the role over time. Note how between the 2007 pdf and future content the Product Owner no longer became a person who has financial accountability. Basically the “Sponsor” part of the role was removed and the role then became a glorified Subject Matter Expert. No other role was created for the elusive person who had money, apparently they have no involvement in the project. I do like the concept of someone being accountable for the “product” but this is still a poor substitute for a real customer.
  • How does a Product Owner know that the features will result in market value? Is it an instinctual activity? Do they do market research? These are questions that I do not believe the Scrum method adequately covers. This is likely why other methods or techniques such as Lean Startup have grown in support.
  • Prioritisation evolved over time to be done as needed, which is a welcomed change.
  • I do like how the current scrum.org definition clarified accountability versus responsibility.
  • The scrum.org details on the Product Owner being a single, highly empowered person is also a welcomed clarification – but it does raise the point that this assumes teams work on one and only ever one product. The reality is that many maintenance, or Business As Usual teams support multiple products and whilst it is nice and warm and fuzzy to have a prioritized backlog from a Product Owner for each product being supported it still doesn’t help the team understand competing factors within the same organisation. Kanban does provide some explanations of how to handle this problem but  it certainly isn’t a part of any introductory readings.
  • It is interesting to see that the “accept or reject the work results” responsibility was added mid evolution and is now removed again. Who is responsible for this if the Product Owner is no longer?
  • I do have a question for the ScrumAlliance agilists – who is responsible for the quality of the Product? If the Product Owner is responsible for the business value, shouldn’t they also be accountable for the quality – after all, almost always when teams get pushed to deliver by a particular date it is quality that the Product Owner chooses to downgrade (at the future cost of maintenance and technical debt).

Scrum Master

In the 2007 pdf we have the Scrum Master defined as:

The ScrumMaster is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices.

In March 2007 the Scrum Master definition was:

The ScrumMaster has three primary responsibilities in addition to leading the Daily Scrum meeting:

  1. The ScrumMaster needs to know what tasks have been completed, what tasks have started, any new tasks that have been discovered, and any estimates that may have changed. This makes it possible to update the Burndown Chart which shows the cumulative work remaining day by day. The ScrumMaster must also look carefully at the number of open tasks in progress. Work in progress needs to be minimized to achieve lean productivity gains.
  2. The ScrumMaster needs to surface dependencies and blocks which are impediments to the Scrum. They need to be prioritized and tracked. A remediation plan needs to be implemented for impediments in priority order. Some can be resolved with the team, some can be resolved across teams, and others will need management involvement as they may be company issues that block all teams from achieving their production capacity. For example, a telecom company recently implemented Scrum and found eighteen items on their impediment list, only two of which were directly related to Scrum teams. The others were company issues that needed management attention.
  3. Last but not least, the ScrumMaster may notice personal problems or conflicts within the Scrum that need resolution. These need to be clarified by the ScrumMaster and be resolved by dialogue within the team, or the ScrumMaster may need help from management or the Human Resources. Certified ScrumMaster James Coplien developed over 200 case studies of notable projects while working at ATT Bell Labs. He reports that over 50% of productivity losses were caused by personnel issues. The ScrumMaster must pay attention to them to ensure the team is fully functional and productive.

Additionally in 2009 the following was added onto the March 2007 version (preceding):

The ScrumMaster is a facilitative team leader working closing with the Product Owner. He must:

  • Ensure that the team is fully functional and productive;

  • Enable close cooperation across all roles and functions;

  • Remove barriers;

  • Shield the team from external interferences; and

  • Ensure that the process is followed, including issuing invitations to Daily Scrum, Sprint Review and Sprint Planning meetings.

In September 2010 it changed again:

The Scrum Master is responsible for ensuring that the Scrum Team adheres to Scrum values, practices,and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. When the Scrum Master helps make these changes, this is called removing impediments.” The Scrum Master’s role is one of a servant-leader for the Scrum Team.

Within scrum.org the definition is now:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. 

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;
  • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  • Teaching the Scrum Team to create clear and concise Product Backlog items;
  • Understanding long-term product planning in an empirical environment;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Teaching and leading the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and, 
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. 

The ScrumAlliance definition of the moment is again sparse with:

ScrumMaster: ensures that the team is functional and productive 

Scrum Master results and opinion

  • Phew… where to start on this one. I consider the SM role to be an art. There is this careful balancing act that needs to be at play in order to enable the team to deliver and creating a self autonomous environment versus advising and teaching. The SM role to me is ultimately about improving the teams whole capability at delivering. How does an SM do this? Through behavioural adjustments – people skills are key so March 2007’s third bullet point is incredibly important, but now lost again.
  • It should be the whole team not just the SM that removes roadblocks. What does an SM do if the roadblock is outside of their control though? Naturally they would help remove it but then this role is beginning to sound like a Project Manager to me… and Certified Scrum Master training says there is no such thing as Project Managers.
  • Shouldn’t the team work out which interactions are helpful or not? Isn’t that the point of the retrospective? The SM is there to question the team and to plant the idea that the interaction may not be ideal but ultimately it is the team’s choice. That is what makes a self-empowered environment.
  • Shouldn’t the SM be responsible for also ensuring the team is following first and foremost the Agile Manifesto and principles? I’ve seen plenty of teams that do the practices but then don’t treat each other with respect or have the courage to call out dysfunctions when they see them.
  • What is ‘Scrum theory’ exactly? I suspect it means reading a whole pile of books and blogs because the detail doesn’t exist anywhere else.
  • Facilitating sessions should be a temporary activity for the SM – ideally this would be rotated within the team as capability improves.
  • Ideally the SM role should not take more than 10% of a person’s time (assuming a 8 person team). How much time they actually need to supply depends on three factors – team size, team Scrum capability and the stage of development (ie first sprint or 10th sprint). A team that doesn’t know Scrum will take longer to depend less on their SM. A three person team will transition generally quicker to a position not requiring a dedicated SM faster than one with 10 people. A team that is in their first sprint are still going through Forming, Norming, Storming, Performing and so will depend on their SM more to resolve some of the personality issues. Most Scrumists say it is a full time job, I normally advocate a half bell curve over the life of the project. As the dependencies decrease the SM can then actually start helping delivery of stories (ie can contribute on a different level). Nothing in the descriptions above deal with the timing nor in the contribution levels of the SM.
  • The term ‘coaching’ is misleading. More often then not the SM is training and advising the team. True ‘coaching’, which I do believe is also needed, gets the team or individual to self reflect to reach answers to problems.
  • The recent scrum.org definition now combines the SM and Agile Coach role. These are different roles and shouldn’t be combined the way it has been explained. In a small organisation then without a doubt it would be combined but it really is a different ‘hat’ that is being put on. An Agile Coach grows the capability of Scrum Masters, provides an overall adapted framework for the culture of the organisation and works on changing the mindsets of senior executive managers. In the terms of Shu-ha-ri: the team is in Shu, the Scrum Master is normally in ha and the Agile Coach is normally in ri. Choosing an implementation model is no small feat either but as always comes down to its own implemention of Agile – ie create an implementation backlog, prioritise, estimate and work to deliver results frequently.

The Team

In the 2007 pdf we have the Team defined as:

The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional. A Team is responsible for figuring out how to turn the Product Backlog into an increment of functionality within an iteration, and managing its own work to do so. The Team members are collectively responsible for the success of each iteration.

In both March 2007 and March 2009 the Team definition was:

The Team:

  • Is cross-functional, with seven (plus/minus two) members;

  • Selects the Sprint goal and specifies work results;

  • Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal;

  • Organizes itself and its work; and

  • Demos work results to the Product Owner.

Within scrum.org the Team definition is now:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

 The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
  • Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

 Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog. 

The ScrumAlliance definition of the moment is:

Team: self-organizes to get the work done 

The team results and opinion

  • Again scrum.org is coming up trumps in providing a really well thought out and detailed explanation including for the first time differentiating that the Development Team is subset of the Scrum Team.
  • The recent version of text from scrum.org also explains a lot further what ratio of time size is preferred and justifies this well. The 7 (+/- 2) model was too restrictive. People may often miss the fact that this is more a guideline then a rule.
  • I am frustrated with terms such as ‘Development Team’, ‘testing’ and ‘business analysis’ being used as eludes that Scrum can only be used for software development. Yes I understand that software development was it’s starting place but I would be more generic and say ‘Delivery team’ instead.
  • The use of the term ‘cross-functional’ is also a pet hate. Only the recent scrum.org definition covers the depths of what it means in adequate detail but even then a major point is missing – why is a cross-functional team recommended? Ultimately it is because you want to achieve the sprint goals without having to depend on external factors. As soon as you have dependencies on those outside of the team to deliver user stories within the sprint then you are introducing risk. Many people miss the fact that a cross-functional team means a team that is first and foremost focussed on achieving the sprint goals (and when I say sprint goals I mean more the product backlog items that have been pulled into the sprint backlog). All too often I see team that have coded and ‘delivered’ the software for the stories inside of the sprint, but the testing is incomplete at the end of the iteration AND the developers have chosen to start new stories rather than help achieve the sprint goal – ie they would rather develop then help out testing to get the sprint achieved. The second intent behind the cross-functional team is that these developers should be focussing on the goal rather then their specialised domain. Where this gets interesting for me is when this is a regular occurence – ie the team are often performing duties outside of their standard specialisation. This is a smell for me. When this happens often –  does this mean that the sprint goals are achieved? Yes. But does it do it at the expense of the team’s engagement? Yes. I would argue that if you put a great developer on testing duty for 75% of the project they will be highly unmotivated and it is for this reason that I actually believe the term should be “cross-skilled” rather than “cross-functional”. Cross-skilled infers that you can help out when needed, but that it shouldn’t be the norm where cross-functional is a little more open ended. My adapting too much to issues through a cross-functional team you are likely avoiding a particular flow constraint issue.
  • Some of the wording in the earlier versions is suggestive that the team is the one  that chooses priority – eg ‘selects the sprint goal and specifies the work results’. A clearer wording would be ‘determines how much can be achieved inside of the sprint and defines a way of working that will achieve this’.
  • ‘Demos’ is probably not referring to a showcase and more a ‘hey, we think we have this story right – can you take a look?’
  • You can see how a single word has a lot of potentially inferred meaning behind it – it is for this reason that short descriptions of roles and responsiblities are fraught with danger.
Anything else?
  •  I’m really getting a theme that the ScrumAlliance doesn’t want you to know anything more than a single sentence so that you have to go on training. A cynical person might think that it is a nice model to generate more revenue. For this I have to give scrum.org kudos of not shying away from giving something more meaningful to its readers.
  • So where is the Project Manager in all of this? Scrum says that no such role should exist, nor needs to exist in a self-autonomous team but then that eludes to a governance model that is not consistent in a lot of organisations. Often, organisations have a gating process before work starts and whilst delivering Sprints they require Steering Committee oversight – who should be part of this within the team? The Scrum Master? In an ideal world the Steering Committee would turn up to the showcase and see the output to be comfortable. In an ideal world system environments would be in control of developers and not require negotiations with an external team. But most Scrum teams don’t live in this ideal world. There are inevitably external factors that mean the team isn’t in full control of its complete destiny and this is where a project manager can be effective – in ensuring that the team is effective. They are externally, outbound focussed handling pressures outside of the team.
  • I have seen many projects that have software development components to deliver but at the same time have other components that have to be aligned – such as marketing/communications, training, business process re-development. Normally I treat them as all part of the one team as their stories will affect the success of the ‘product’. They have their own user stories which are prioritised against all the software development work, any dependencies are recognised. Because their work often only comprises < 5% of the end to end work I consider them part of the ‘extended team’. In this respect I have two ‘teams’ – one is the core team who delivers a majority of the stories. These are the people who are full time on the project. Anyone else is part of the extended team. This concept of two teams is not reflected in any Scrum content.

Read Full Post »

Daily retrospectives

Inspect what is inside

Daily retrospectives are is not a new idea, but it is important to recognise and re-iterate that there are other things than just running a retrospective at the end of each iteration.

Consider the heart of Agile for a moment – it is a reflective improvement framework aimed at dealing with the complexities of imperfect human beings and software development. If the heart if Agile is reflecting to improve why are we only doing it once an iteration? Should we not be ideally aiming to do it more often, or most importantly, when it is most needed?

So to re-iterate, here are the steps to enabling daily retrospectives:

  1. Whomever owns the daily standup meeting invitation updates it to tack on an extra ten minutes. This doesn’t necessarily mean you will use this extra ten minutes each standup but it is there if you need it. Regardless having an extra ten minutes booked into everyone’s calendar is always a good plan in order to deal with off-lined conversations or road blocks that were bogging the standup down.
  2. Put up a board near your story wall that has the questions that you want to be addressed as part of your retrospective – for example ‘what’s working well’, ‘lessons learnt’, ‘what still puzzles me’, ‘what to do differently’.
  3. Throughout the day if you have something that you would normally put up against your retrospective questions then jot it down on a post it note, with your initials circled next to it.
  4. The next time you pass the wall check to see if that item is already on the wall or not. If it isn’t put it up, if it is, add your initials next to it. This is a great opportunity for you to check other notes that are up on the wall and if you agree with the item add your initials.
  5. Every now and then as you pass the retrospective wall if you see something new then read it. If you agree add your initials, this is like social networking ‘+1 like’.
  6. Agree to a ‘like limit’. For intensive purposes this behaves like a work in progress limit.
  7. Once you have reached the like limit at the end of the next stand-up you will invoke the extra ten minutes and ‘pull’ that liked retrospective note into play. Discuss the item as per a normal retrospective but don’t cover off any of the other notes. If required delve into the root cause and ensure that you have clear SMART actions. Any actions should end up being a card that is prioritised by the team and added at the appropriate place into the backlog.
  8. If necessary discuss how often the wall should be purged of singular notes. This may mean that the practice evolves to include adding a date for when it is initially raised.
The advantages of such an approach:
  • No long meeting to discuss the iteration at length, but the time might end up being the same in the long term if you are pulling a daily retrospective often enough.
  • Focussing on problems sooner rather than later (assuming it gets liked quickly enough)
  • Focusses on items of greater importance but still gives great broad visibility

Read Full Post »

Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers