Agile Forest

Find your path to agility with Renee Troughton

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?

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

 

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.

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

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. 

shortcutRecently reading Dan Pink’s Drive, I was mesmerised by a statement of leadership type classifications. I wondered whilst reading it if there was a way to short cut the interview process to get the right type of leader by asking the following question:

We believe here at <Company X> that people fundamentally dislike work and would avoid it if they could. They don’t take responsibility for their actions and badly need direction. We want managers at <Company X> to co-erce, control and direct their staff to put adequate effort to the achievement of the organisations objectives – are you the sort of person that relates to this and can help us with this?

Now what you are actually seeking here is not a positive affirmation. What you are seeking is the look of shock and horror. The right person is the one that says “I’m sorry but this is definitely not the place for me; thank-you for your time,” and walks away. Most people wouldn’t do this, they would dance around the question, but a real leader is the type of person that will stick up for their beliefs and despite the negative impacts to them will stand firm. It takes juts to say no to this sort of question, especially this early in the process of understanding the organisations culture. It takes honesty to speak true to your beliefs. It takes a leader and not a manager to negatively respond to this question.

What do you think? Would this short-cut work if you were trying to hire an Agile leader?

In a recent tweet,

If you must do some pre-project prep, so be it. Please don’t name it “Sprint 0″ that makes it seem valuable. It isn’t.

Delving further into the tweet I learned that “many use Sprint 0 to enable bad habits” (don’t disagree), that it maybe should be called “project chartering” instead and that a more common definition of a Sprint is “a time-box for delivering a Product Increment”.

So what is the common goal of a Sprint 0?

Starting-Line-300x200The Sprint goal (by my definition) behind a Sprint 0 is “being ready and able to deliver business value that is usable and potentially releasable”. If you are ready to deliver business value then Sprint 0 is officially done.

Do all projects need a Sprint 0?

I say projects here quite deliberately as a team that is already functioning and already delivering are highly unlikely to need a Sprint 0 unless a specific set of features coming up dramatically impacts the ability to deliver business value inside of the Sprint.

If your organisation is onboard the DevOps train and XP practices are well established then you may not need a Sprint 0. If environments can be created and built upon in a day, if standards and frameworks are well understood then you may be ready to start delivery business value straight away.

This ultimately is highly dependent on your organisational capabilities.

Where does story elaboration fit in with respect to Sprint 0?

Teams quite commonly use the time whilst in Sprint 0 to also elaborate further the User Stories for the first value delivering Sprint.

You don’t have to have elaboration one Sprint ahead, but it can potentially help reduce carry overs, reduce time spent in Sprint Planning and ensure that task cards (if you use them) are well defined.

In an ideal world User Stories would be small enough and complexity low enough that carry overs are minimal and elaboration can occur within the Sprint.

What cadence activities should occur in Sprint 0?

Sprint 0 should be, from a process perspective, exactly the same as any other Sprint. It should be planned upfront through Sprint Planning, work should be broken down into items that are achievable within (ideally) 1-3 days, it should be slapped up onto a story wall/task board and tracked, Daily Scrums should talk about what everyone is doing and enable collaboration and sharing. At the end of the Sprint you should demonstrate what you have achieved within the Sprint Review, “Hey take a look at this box, this is the box that builds our code and automatically deploys it. Here look at it compiling and this is the result (good and bad) that it generates”. The Product Owner may not care but I can assure you the rest of the team will. Additionally it is a great opportunity to start reflecting about how you have worked together as a team and see what can be improved.

Just as per other Sprints the work that is done in Sprint 0 should be prioritised. If it doesn’t enable you to deliver software in a Sprint then it probably isn’t high in priority.

So in essence, all the standard, normal Sprint activities that occur when business value is delivered should also occur in Sprint 0.

How long should Sprint 0 be?

Just like value delivering Sprints, Sprint 0 should be timeboxed. The ideal value to set this timebox to is the same duration of your value delivering Sprints. When you do this it is a great test to see if the Sprint length works for you and also a great test of your planning process – were you able to achieve what you had planned?

The trouble with this is that in almost all cases the team’s velocity has not been established and consequently the likelihood of not delivering to expectations is high. If you are going to fail on estimation versus delivery (which I can safely say you will) then this is the time that it first shows itself. This then sets the team on a slippery slope as already from the first Sprint you are behind expectations. How will management react to this message? How long will it take for pressure to be pushed onto the team?

For low DevOp maturity organisations it is entirely possible that the time it takes to get ready to deliver value is longer than a Sprint. This is where the concept of “Sprint 0″ as a term fails and you see people then try to fix it through using “Sprint -1″, etc. This slippery slope further erodes management trust.

I fail to see a magic bullet for this particular problem other than having good planning upfront and always asking “do we really need to do this to begin delivering value?”

What if the team is able to deliver value earlier than then when the Sprint will end?

Then start delivering value. If it is a week earlier, you might want to re-organise the Sprint start and end dates. If it is a few days then it is probably a good idea just to let the Sprint run its course and ignore the velocity for the Sprint.

What if the team is unable to deliver value by the end of the Sprint?

If there are just a few outstanding items then start the first business value delivering Sprint, being cogniscent that it will impact your velocity a little. If there are considerable outstanding items then this should be discussed in detail at your retrospective. Why did this happen? Was it because impediments were not removed? Should an additional Sprint be added? If another Sprint is added then does it affect the ROI of the project? Should we just call it quits now?

How long after Sprint 0 is finished should you wait to start doing Sprints?

Don’t wait. Get started delivering that value!

Where does team onboarding fit in?

The day you start Sprint 0 is the day all the team should be onboard. Arguably they should have been onboarded earlier when you initially created a Product Backlog through Inception workshops.

What are the common pitfalls of Sprint 0?

The obvious one is that teams never get started delivering business value. They stay in this mode of never being ready and there is no drive or motivation to move out of it. Sometimes this is for very valid reasons, for example, developers don’t have PCs or an environment to work in; but often it can be just rats and mice outstanding.

This is why it is important to have Sprint 0 considered a Sprint because the Scrum Master should be driving the team to the goal of delivering value in a predictable manner.

So what is the Scrum Guide definition of a Sprint?

The Scrum Guide defines a Sprint as:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

So by the above definition it is wrong to call everything that I have said above a “Sprint” because it doesn’t result in a potentially releasable product.

But the Scrum Guide goes on to say:

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work,
the Sprint Review, and the Sprint Retrospective.

which aligns with the above activities that should occur as you prepare to deliver business value. Not surprisingly the Scrum Guide does not say anything about Sprint 0, mostly because anything that is before Sprints fails to exist as a process step or activity (the initial backlog creation being a great example).

What’s in a term?

If you should have for Sprint 0 a Sprint Planning Meeting, Daily Scrums, dev work, Sprint Review and Sprint Retrospective why would you not have a term for this special case that does reflect the word “Sprint” in it, after all, three of the cadence activities in them have the word “Sprint” in them.

If you want to use a different term, lets say “Project Chartering” then you are still having a Sprint Planning, Sprint Review and Sprint Retrospective… but not in a “Sprint”. This seems a little odd and misleading to me.

I feel that the messaging to people starting Agile should be clear and simple and removing the word “Sprint” does not align logically with that. I feel that the word “Sprint” is incredibly applicable and that the definition of “Sprint” in the Scrum Guide needs some common sense flexing of interpretation. I don’t expect the Scrum Guide to change, but do expect some guidance somewhere about how this pre-Sprint is a special exclusion from the delivering of value component in the guideline.

You could always just change the name of all the cadence activities but I think that goes back to not having a simple message.

So what would I call it? I agree that the ‘0’ in ‘Sprint 0′ is misleading. I would call it something like ‘Delivery Enabling Sprint’. Make the implicit explicit.

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?

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?

Firstly I do apologise for the long absence on the blogging scene. This was in part due to my shift from Brisbane to Sydney, lack of internet, lack of technology, but also due to illness. So for my first blog back for the year I would like to implore you – PLEASE if as an adult you haven’t had any form of immunisation then go see a doctor and get some shots!

I was under the mistaken belief that I was fully immunised and didn’t need anything further in my adulthood and have been surprised to find that I was not covered when I got hit with Whooping Cough. Having been out of the country when the big Australian hoopla happened about Whooping Cough I was terribly ignorant of it and didn’t realise just how bad a bacterial infection it was. I am now six weeks into a three month problem and every day is very hard. 

micro

Thankfully I didn’t share it with anyone (but sadly my kids did give it to me as carriers). Anyway, onto the blog at hand.

My preference over the years has always been to work with User Stories as my lowest level of work. I have never really felt like I needed to break stories further down into tasks in the manner in which Scrum does. The reason for this is fourfold:

  1. I like my stories to be no bigger than four days. Ideally they are around the 2-3 day mark to deliver end to end. If they are this small then individuals can still be held accountable for progress on the story.
  2. I have rarely seen teams care about how a Story is being delivered whilst it is in progress. The fact that a team member is working on the unit tests now and then will be going onto the database changes has little consequence to the functioning of the other team members. The ‘aha’ and roadblock moments I see coming out of the Daily Standups very rarely arise from technical implementation at a task layer.
  3. The time it takes to break the user story down could be considered waste. For me the value in estimation is not the number you get, but the conversation of assumptions, dependencies and constraints that you have on the way to get an estimate. You can still have these conversations when planning the iteration.
  4. The extra time that it takes to generate a Burn Down chart. I would rather have a look at the where the stories sit within the flow against the current day of the iteration and see if the team is behind/ahead from that. It isn’t a science like the Burn Down chart, but if you really think two to four hours is going to make a big difference you are probably looking at the wrong things. I find that teams that focus solely on hours being Burned Down only tend to have a lot of carry overs due to a lack of focus on getting the story wholly to done.

So recently I started working with a team that, when I joined them, were already using tasks and hours to track.  I made a conscious decision to not change or influence their desire to use tasks and consequently through myself with gusto into ensuring that all stories within the current iteration were fully broken down into tasks, estimated and tracked via a Burn Up chart (at the time there was too much volatility in the iteration from a change perspective to use a Burn Down).

What I found didn’t really change my dislike for tasks or burning down hours in the iteration but it occurred to me that when I focussed on work at an hour by hour basis rather than a day by day basis that I was becoming a scrum micro-manager. I instantly cringed at the realisation and wondered how empowered or autonomous the team felt from when they were being tracked at this layer.

So I asked them whether they felt that being tracked at a task layer, hour by hour felt like they were being micro-managed – the results? 71% of the team felt that it wasn’t micro-management, leaving 29% to feel the opposite. It would be interesting to see how this co-relates to performance, but I don’t think I will go into that on a personal blog.

Two of the team members did say they didn’t feel it was micro-management but expressed concern at the sheer visual weight of the number of cards on the wall. To put this into context at the moment we are mid iteration and have fourteen stories (consequently rows) in scope and around one hundred task cards flooding through the wall. This is ignoring the cards that are being fleshed out an iteration in advance (let’s ignore this slight scrumfall-ish behaviour), the product owner decision cards and the eighty story cards in the event horizon backlog. I do try to clean up the done work every day so that it looks a little less scary visually but at the start of Iterations I can definitely see it being a concern.

So what do you think – is it micro-management to track to the hour using tasks in Scrum?

Follow

Get every new post delivered to your Inbox.

Join 993 other followers