Feeds:
Posts
Comments

Archive for the ‘Agile’ Category

Why Scrum really works

magicThere are some great things about Scrum. Having a regular cadence for planning how to do work, working together to progress work and regularly reflecting and getting feedback both on how we work together and what was delivered are all great concepts.

But I have come to a somewhat scary hypothesis that it isn’t the practices, the roles and the artifacts that are actually making Scrum successful.

I think it is because you are taking your inefficient, over bloated process and replacing it with a very simple method. It works because you are taking something very heavyweight and replacing it with something lightweight.

You see, the trick to succeeding at Scrum, isn’t really the implementation of Scrum. It is whether you win the culture over process race.

As you get more used to Scrum you find weaknesses, areas where it isn’t dealing with organisational problems and you start to add in process to fill the gaps. Usually what you add in is something similar to what you used to do. At the same time, you are trying to transform the culture by changing hearts and minds towards Agile – to be agile rather than just doing Agile. This is the culture shift. When you have succeeded in this culture shift you would be less likely to introduce the additional process.  Basically you have to be faster at changing the culture to enable pushing back on process bloat over the injection of new process.

This is arguably why SAFe could be a little less effective in transformation and in significant improvements – because to an extent the process is probably more medium-weight and doesn’t do enough to push back on process waste.

So the next time you plan on changing a way a team or organisation works, think about why it may be working and focus on whether every additional step being added in after the change will really add value. I find that 80% of process is added in to handle less than 5% failure scenarios. There has to be a better way.

Read Full Post »

earthAgile and Lean have come a long way for the last ten years, but I feel there is a barrier that we cannot break through without a dramatic disruptive force. For years I have been wondering what could drive this. I had hoped that Stoos could have been a means to this change, or that continued and persistent adoption of Agile and Lean would result in it, but I hold little hope for these being the avenues to it. I know they will, given enough time, but I hold a fear that the continued models that our government and teaching system uses will not result in a change in my lifetime. And my even greater fear is that by then it will be too late.

I met recently with one of the worlds leading climatologists and asked deep questions regarding our future as a race. There is clear evidence that within one hundred years it will be on average ten degrees hotter across the globe. If you thought that I was wrong writing ten and not five then make no mistake – they are telling the media five degrees so that it doesn’t cause massive panic and so that they don’t appear to be fear mongering, but the real expected figure given current global politics and policy is ten degrees.

With ten degrees there would be widespread drought. Half of the planet would be inhabitable. Ground level railway systems would fail. Heat stroke related deaths would be significant. Imagine how we would live, how much we would have to seek travel out of the sun, how much extra energy we will be burning to make ourselves cooler. I have children and I want them to be able to have a future where they can enjoy being outside.

I want a world where the politicians listen up and start to address this problem. I want a world where the people within it get to have a voice beyond an election every few years. I want a less apathetic world.

Where I have seen Agile transformations highly successful is ironically when they have been driven from the top – a desire at the upper levels of organisations to create a new culture.

So I want a massive disruptive change, something to address this problem. But how?

I have some ideas, but I am keen to hear yours – do you think a disruptive change is needed? If so, what do you think can be done from it, different to what we are doing now?

Read Full Post »

Last week I revealed a little game/exercise that I have been running to demonstrate the difference between activities and behaviours in a non Agile environment versus an Agile environment and how the activities and behaviours shift to the team and the Scrum Master/Iteration Manager. I would like to now share the results of the game. I have run it twice, one with a strong group of Agilistas (Scrum Masters and Agile coaches) and a second time with a group of Project Managers. What surprised me is that despite the differences in the audience the result was pretty much the same. Maybe it was luck, but I am keen to hear of others running the exercise and if they get the same results (a few people have already shared with me that they have subsequently run it and got a similar outcome). The group of Project Managers that I did the activity with had a really good smattering of Agile practitioners in it which I believe helped to get a similar outcome. In this respect, I am concerned what the outcome would be like with a pure audience of Prince 2, never done Agile, Project Managers.

So what were the results for round 1?

When round 1 is conducted, almost all cards are voted to be best aligned with the role of the Project Manager. The following were the behaviours/activities there were not voted to be a Project Manager’s:

  • Deliver the work right
  • Deliver value
  • Quality focused
  • Is 100% allocated full time
  • Delivers the right work
  • Challenges the norm
  • Encourages learning culture
  • Mentors team

Which left the Project Manager with the following behaviours/activities:

  • Facilitates meetings
  • Primary stakeholder is Sponsor
  • Primary stakeholder is the team
  • Primary stakeholder is customer
  • Sustainable pace focussed
  • Coaches issues
  • Manages ability to deliver outcomes
  • Removes roadblocks
  • Trains approach
  • Resolves issues
  • Enables rather than controls
  • Makes decisions
  • Handles people issues
  • Directive, provides answers now
  • Has budgetary control
  • Ensures benefits realisation
  • Delivery focused
  • Supports approach

My thoughts on the round 1 results

The following were my thoughts on the results for round 1:

  • I thought it was interesting that it was the team and not the PM that was perceived to challenge the norm. Is this an admonition from PMs that they don’t push back on unrealistic timeframes or goals?
  • The PM’s primary stakeholder is considered the team, the customer and the sponsor… all at the same time. This question was deliberately worded to force a ‘x over y’ response and yet there was a strong drive for all three roles to be the primary focus for the PM. The conflict between these roles is inevitable and in my belief this is the key weakness of the non Agile environment model – one of these roles will win out over the other two and in my experience, it is unfortunately not the team nor the customer that wins.
  • I was somewhat surprised that PM’s felt that facilitating meetings was a core behaviour/activity. I normally would have thought this would have gone to the Business Analyst role but it could depend on how you interpret the question and what facilitation means.
  • I was very surprised on the sustainable pace response. I believe there is a gap here of what PMs believe to be true versus reality. When push comes to shove, most PMs I know would push the team to work extra hours/weekends to get a project over the line. I know that there are many of you who are good PMs that don’t do this, but the majority would.
  • Additionally I was very surprised that a PM would be coaching issues. Again this may come down to an interpretation of the term “coach” but I am using it in the purest sense that of ‘not providing answers, but instead asking questions to the team so that they themselves reflect to reach enlightenment on the issue’. I’m sorry, but I actually don’t think I have ever seen a PM do this.
  • Likewise I’ve never seen a PM train anyone.
  • Enables benefits realisation is a tricky one. I do believe that PM’s care for and look out for benefits realisation, certainly very much at the start of a project, but as the project progresses and trade offs begin to be made it is the better of the PMs out there that deliberately report and get validation to the trade off of benefits against time. That said, few PMs stick around long enough to see the actual benefits realised which I believe is sub-optimal as they are not receiving feedback on how well or not they hit the mark on delivery (to me delivery is more than just dates, cost and scope).

What were the results for round 2?

When round 2 was completed, the Scrum Master was given:

  • Facilitates meetings
  • Coaches issues
  • Enables rather than controls
  • Primary stakeholder is the team
  • Removes roadblocks
  • Mentors team

The team were given:

  • Delivery focused
  • Sustainable pace focused
  • Deliver the right work
  • Deliver the work right
  • Is 100% allocated full-time
  • Delivers value
  • Quality focused
  • Supports approach
  • Challenges the norm

Split very evenly between both the Scrum Master and the team were:

  • Manages ability to deliver outcomes
  • Resolves issues
  • Trains approach
  • Makes decisions
  • Encourages learning culture

The Product Owner was given:

  • Primary stakeholder is customer
  • Ensure benefits realisation
  • Directive, provides answers now

The following were put into the category of “Other”:

  • Handles people issues

And lastly, the Project Manager had:

  • Has budgetary control

The following was questionable as to where it belonged (if anywhere):

  • Primary stakeholder is Sponsor

My thoughts on the round 2 results

The following were my thoughts on the results for round 2:

  • What is most clear in this transition are two things, firstly the Project Manager is left with only one responsibility and the rest have been quite evenly spread between three roles – the Scrum Master, the team and to a lesser extent the Product Owner.
  • Secondly, there is the separation of primary stakeholders against role. The Scrum Master has the team, the team has the Customer and no one is left looking after the Sponsor. I don’t think this is necessarily correct and would imagine that the Product Owner has the Sponsor’s back, but this would likely also have a conflict against the Customer’s needs. What do you think – in an Agile world, who has the Sponsor (the supplier of money) as their primary stakeholder? In an Agile world should a “Sponsor” exist and if not where does the money come from?
  • I love that in an Agile world it becomes everyone’s responsibility to guide others (trains approach), encourage learning, resolve issues and make decisions. Some may argue ‘what if the team disagrees between themselves on an approach’? This doesn’t mean that it goes to a vote for the decision, it means that the team works through the pro’s and con’s and becomes more aware of the depth and breadth of the issue. A leader will always step up for the decision, but it is only done after a more collective understanding is reached.
  • Sustainable pace is probably the hardest issue to balance in an Agile environment. There will always be a push from the Product Owner and management to go faster and harder, especially if there is the ‘frozen middle’, a layer of management that does not understanding the essence of Agile. Dates are commonly still unrealistic for many teams and this leads to the inevitable push to work longer hours. Now with the Scrum Master accountable to the team they will likely be the first to push back against this, but the pressure can be immense. For my two cents I have sometimes given in on having a short burst of extra hours, never longer than a month. But let me be clear, I do not believe it helps the team in the long run, nor do I believe it is a good idea due to the impact it has on the quality of the product. This has been proven many times in studies and I have seen the results of even a month of bursting and what it does. Just don’t do it.
  • It is interesting that the Product Owner is seen to be directive and provide answers now, but if you think about it, to some extent that is what we are asking them to do. We want them to give us a quick resolution on a question so that we can meet our goals.
  • Handles people issues was shifted out as it was now likely being handled by a Team Leader.
  • And lastly, the budget problem. If a PM is only left with handling the budget then is it really a role? There is a huge shift towards “Feature teams” – teams that do not form and disintegrate on a project by project basis. In essence work is broken to fit into them rather than teams being formed to fit the work. This results in teams that only go through the Forming-Norming-Storming phase once at their initial creation or subtle dynamic change. The individuals in the team know each others strengths and weaknesses and most importantly they have a fixed team cost. If all work in the organisation is broken down to features that are implementable by the product feature teams then the problem of funding for software development really just boils down to one fundamental question – “What is the most highest value work that this product feature team can be working on?” Then it becomes a somewhat simplified matter of watching the cycle time for the product backlog and seeing the lead time for features to determine if more feature teams are required for that product, or less. In essence, it takes the problem from being a project issue to being a operational issue.

Final thoughts

theory_x_y

For those Project Managers out there that are believers in “Theory Y” there is unlikely to be much of a negative impact on you when you shift into an Agile environment. You are already a supporter of empowered teams and consequently this transition should feel very natural and in a lot of respects will result in a better work life balance for yourself as your old duties get spread more when you take on either the Scrum Master or Product Owner role.

But for those Project Managers who align more strongly with “Theory X” then there are some tough choices for you ahead in your future. You can choose to find work in an alternative organisation that isn’t about to go down the Agile path anytime soon. There are still plenty such organisations out there, but be aware that over the next ten years the number of these will likely shrink.  You may not be able to run forever. You can try to hide. You may be lucky and not have a good number of Agile Coaches in the organisation who will spot you and elevate your “Theory X” ways to management. PMOs are great hiding grounds, until they are wiped clean.

Or you can change. It won’t be easy, in fact, it will be months and months of hard work, but you may find an enjoyment and peace that you never experienced before when you make this leap of faith.

For the “Theory X” managers, let me leave you with this parting quote and good luck on your journey.

It is difficult to get a man to understand something when his salary depends upon his not understanding it. Upton Sinclair’s Dictum

Read Full Post »

How far we have come…

I know I am an idealist. I don’t think I have ever met a coach who isn’t. It is part of our nature, the continual strive for perfection, the search for true north, the Kaizen culture of always seeking ‘better’. 

This means that sometimes I am never appear happy with the status quo. 

It isn’t that I am not pragmatic and it’s not that I don’t want to live in reality. It is that I just won’t be happy to settle with inefficiencies. 

But sometimes this means that we forget just how far we have come. 

I was reminded of this recently when an ex-team member began to regale to me their surprise when they went from an Agile environment back into a non Agile company. 

To quote, 

At the new job site we’re not allowed to talk to each other unless we make an appointment or go through some formal process.

I tried walking over to talk to a developer last week and was apprehended by a “minder” who detained me and walked me through the correct process to communicate with him.

I guess the idea is to let the developers concentrate on their work without being interrupted but it just seems very slow and inefficient.

It is interesting to note how quickly when going back to non-Agile environments you pick up on the waste surrounding you everywhere. 

So for those of you who are coaches, Scrum Masters and Iteration Managers, battling away at inefficiencies and waste, take a moment to appreciate how far you have come. Remember what it was like when you weren’t doing Agile. Today was better than yesterday. Tomorrow, anything is possible.

1551-captain_america-comics-idealism

Read Full Post »

At a recent Project Manager meetup group in Sydney, I wanted to spend some time covering the difference between the Scrum Master versus the Project Manager role. I figured what better way to do this than to have the group themselves collaborate in an Agile way to guide the answers?Scrum Master vs Project Manager

So I created the Behaviours And Responsiblities Game, or BARG for short.

Let’s go into how it works:

  1. Setup enough voting cards for everyone in the room. There are four voting cards for each person: Team, Other, Scrum Master and Project Manager
  2. Round 1 kicks off with only using the Team, Other and Project Manager voting cards. Headers match these cards on a wall. Preset cards are read out of behaviours and responsibilities that are commonly encountered in project teams and the voters are encouraged to nominate which role predominantly performs the role or exhibits the behaviour. Round 1′s key context is that of an environment that is not Agile. It could be waterfall, it could be RUP, it could be pure common sense.
  3. As each behaviour/responsibility is called out the card is placed against the role with the highest number of votes. If you have more than 40 minutes than feel free to use additional time to discuss variances where they are quite opposed. Cards can sit between two roles to show the varying opinion.
  4. Round 2 is kicked off with exactly the same set of behaviours and responsibilities. New headers are placed for all four roles which now includes the Scrum Master. It is also recommended to include a Product Owner role. Round 2′s key context is that of an environment that is Agile.
  5. Step 3 is repeated again.
  6. Take time now to compare the results between the non Agile environment and the Agile environment. Walk through any placements you disagree with but take care not to move any placements.

The cards that I included:

  • Facilitates meetings
  • Primary stakeholder is Sponsor
  • Sustainable pace focussed
  • Coaches issues
  • Manages ability to deliver outcomes
  • Primary stakeholder is the team
  • Removes roadblocks
  • Trains approach
  • Resolves issues
  • Enables rather than controls
  • Makes decisions
  • Handles people issues
  • Directive, provides answers now
  • Has budgetary control
  • Primary stakeholder is customer
  • Ensures benefits realisation
  • Delivery focussed
  • Is 100% allocated (full time role)
  • Deliver the right work
  • Challenges the norm
  • Quality focussed
  • Deliver the work right
  • Delivers value
  • Mentors team
  • Encourages learning culture
  • Supports approach

Bring along a few blank cards and feel free before starting round 2 to ask if any key behaviours or responsiblities for the Project Manager have been missed. I found that I had missed in retrospect two:

  • Plans timeline
  • Reports to steering committee

So what were the results? Stay tuned, I will post in a week or so. But in the meantime, predict what you think occurred – what shifted where? What didn’t have anyone accountable for it? What was no longer needed?

 

Read Full Post »

Scrum, the most used Agile framework/method in the world, has been responsible for many successful and some less than stellar Agile transformations.

Created prior to the establishment of the Agile Manifesto, but its influences heavily intertwined into the Agile Manifesto, the difficulty I have had after using it for over ten years is that I do not believe that it is adequately adapting to an evolving commercial reality. In essence, I do not believe that it fully supports the Agile Manifesto statement “Responding to change over following a plan.”

The commercial pace is getting faster,  ever increasing demands are being placed on Information Technology. Ten years ago, to deliver into production every month would have been considered unthinkable for most IT shops.  Now days, if you deliver once a month, especially for internet deliveries, you would be considered archaic.

Continuous delivery has helped us to overcome a number of frequent delivery barriers but it seems that it is never enough.

To keep in front of the pack, delivery of software solutions needs to potentially evolving so rapidly that what you are delivering changes on a day to day, hour by hour basis.

If you find yourself in this situation, and this will not be every delivery commercial situation, then the key purpose of a timebox within Scrum is broken.

The intent of the Scrum timebox was to have a period of no change. That at the start of the timebox, given what you were historically capable of producing within the timebox, you would pull in a similar amount of work that was highest priority in the Product Owner’s opinion.  Once the planning was completed then change within the timebox was highly frowned upon – how else could you meet the initial goal without a tight control on holding external factors at bay?

But if your commercial reality is that you have to be adaptable to change within that timebox, that you cannot hold the external factors at bay, then you risk breaking the purpose the timebox.

Some would say that if you try Scrum under these conditions, but without an intention to deliver the contents decided at the start of Sprint Planning that you aren’t doing Scrum, or that you are doing Scrumbut. However, in today’s current commercial climate is this really acceptable?  Is it okay that many are advocating a method that doesn’t easily support the growing needs of us as a software development profession?

Sure you can follow other method. You could have daily Sprints. Alternatively you can rework the timebox to be a regular cadence period where you always conduct a demo and retrospective, but is this still Scrum? And if it is not, then is Scrum ‘Agile’ enough for our future?

Read Full Post »

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 »

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 »

Disclaimer

Firstly, this is an odd sort of post for what I normally write. It is more a brain dump of a concept or idea I have and not necessarily a well formed one.

The audience was for Dave Snowden or anyone else who considers themselves a Cynefin or complexity thinking specialist.

I openly profess I am not. I am trying to learn and so some of the concepts I have within may be wrong. Please forgive me if I haven’t gotten a concept right. I am here to learn, be challenged/corrected and think differently.

These ideas and thoughts were generated from trying to extend the boundaries of a new movement called “Visual Management”.

blog-coffeeCoffee and Cynefin

Coffee at home

When we make a coffee at home it is a very easy affair. We choose the coffee type from the store (probably your hardest decision), add it to a cup, add sugar if you desire, add boiling water, stir, add milk if desired and Bob is your Uncle.

In terms of complexity of the task it is Simple. The outcome is predictable. The process requires no domain specialisation. In likelihood the home “barista” is also the customer. The quality is…. less than desirable. I know that quality is in the eye of the beholder, but having been privy to some of the worlds top coffee makers and blends and I can say, in my experience, that a Nespresso machine coffee pales to a good barista produced cafe coffee.

Cafe coffee

When we go to a cafe for a coffee the domain expert, the barista, should be able to do a better job of producing a coffee from the commercial quality machines than the average person.

In terms of the complexity of the task it is Complicated. The outcome is still predictable. The process now requires domain specialisation. The barista is no longer the customer. The quality is dependent on the experience of the barista, the process they use, the quality and freshness of the coffee  itself, the roasting process applied, the milk and lastly the quality of the tools (machine, grinder, milk jug).

World Barista Championships

blog-mattLast year my husband was Australia’s 5th top Barista (I am very proud of him). His passion and energy for a good cup of coffee has enabled me to learn a lot about the coffee industry. In order to be a rated barista in both Australia and the world there are competitions that are run each year. These competitions are very arduous and time consuming. This year’s barista champion for Australia spent three months, full time, training for the competition event. In essence, he was sponsored, ie paid for three months, to do nothing but ensure that he was ready for a fifteen minute performance. Judges go through a similarly arduous process. Technical, taste and presentation standards exist and are assessed against.

Baristas at this level are highly passionate, highly educated and use the best tools and equipment that money can buy. To be on top of their game they conduct a lot of experiments. For their twelve coffees in fifteen minutes they would make hundreds of bases, cappuccinos, and try dozens of experiments for their signature drink. Dozens of blends would be tested and a variety of roasting conditions tested. Baristas have to work closely with roasters because, in essence, their coffee is also showcasing the roaster’s ability too. The roaster’s domain experience can greatly affect the barista’s outcome.

All in all, a barista, when they start their journey, would certainly not be able to predict the type of the coffee, the roasting elements, the milk to be used and their signature drink. In terms of complexity of the task it is Complex. The outcome is not predictable. The process requires several domain specialists. Experts are now the customer. The quality is high and graded within clear and defined guidelines.

How does this relate to Visual Management?

When we make a coffee at home there is no value in visually managing this work. Simple work will happen with such predictability and ease that the effort to do visual management would be considered an overhead or waste.

When a coffee is made at a cafe there is some value in visually managing this work – value for both the customer and producer. Complicated work has the simplest of visual management techniques applied – the flow is usually limited to “To do”, “Doing” and “Done”. The variability of items inside of the flow is constrained to a subset of possible conditions,that is, a barista is not going to make you a smoothie or sandwich.

When a coffee is produced for the world barista championships the process to deliver that coffee would benefit from a more complicated visual management system. Complex work has complicated visual management techniques applied – the flow may additionally have a “Wait” column. The variability of items inside the flow are no longer constrained to a subset of possible conditions. Work may now become easily blocked. Work may now have dependencies and relationships to other work items. Work may now need specialization outside of the barista’s capabilities – ie other domain experts are likely required. All of these things can be visually managed. You don’t have to have a visual management zone for doing the world barista championships, but speaking from experience it certainly does help.

Conclusion

For coffee making (and maybe more?):

  • There is a relationship between the complexity category and quality
  • There is a relationship between the complexity category and process specialised relationships required to produce the work value or outcomes
  • There is a relationship between the complexity category and variability of work items within the flow
  • There is a relationship between the complexity category and the predictability of the end outcome (known)
  • The visual management techniques applied sit one category of complexity below the actual work within the system

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 »

Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers