Archive for the ‘Uncategorized’ Category

Agile doesn’t work

agiledoesntworkOn my way to someone’s desk at work I overhead a blunt and emotive statement “Agile doesn’t work”. I smiled slightly and hung back to overhear the conversation further.

I learnt through listening that the person making the statement was a Product Owner. They were unhappy with the fact that their team hadn’t been delivering on their product backlog, that they team instead had gone off and begun to work on something else.

I was a little shocked to hear this, and could deeply empathise with the concern. If it was the case then the team was indeed not performing to expectations.

I spoke to the Scrum Master later about it (note they were not a team that I had direct coaching involvement with) and learned that team had actually begun working on something else because it had been a directive that had come down from several layers above the Product Owner.

Delving further, the reason why the Product Owner only knew about this after the end of the Sprint was because:

  1. They were not investing their time co-locating with the team
  2. They were not attending the Daily Scrum nor Sprint Planning

… and people wonder why Agile gets a bad rap.

So the real issue here was never that Agile didn’t work, it was that:

  1. The Product Owner wasn’t investing properly in their role, either because they were overstretched (poor capacity planning), or due to care factor (bad engagement)
  2. The Product Owner wasn’t co-locating, again either to being overstretched or due to physical desk limitation issues
  3. The Product Owner was superseded by his own management and yet his management failed to inform him of this change in direction

Some would also say that the fact that the Product Owner’s management trumped his work is an indication of concern, that he may not be empowered to calls the shots. Normally I would suspect such a problem, but in this instance this was an urgent unplanned change that impacted hundreds of people and dozens of teams, it was highly irregular.

I asked the Scrum Master if they would be willing to talk further through the above problems with the Product Owner in order to reach a common understanding of where the problems with Agile in the team were.


Agile does work. It, just like any process, needs people to understand the process and follow the steps to enable it to succeed.

Read Full Post »

In my last post I opened up the questions about a disruptive force out there to induce change and what potential options may exist.

In this post I am proposing an option – the creation of a political party where its foundations lie in the values and principles of Lean and Agile.politics

This party could be funded through crowdfunding, with a policy statement drafted to kick it off.

An example of a political direction could be:

Intra Government Reforms

  • Have the people of Australia determine where spending should go using a model similar to Luke Hohmann’s work in San Jose
  • Significantly reduce the management layer in the government, ensuring that servant leaders were in leadership positions
  • Normalise and make all salaries transparent, using a model similar to Buffer
  • Remove all bonus systems, focus on intrinsic motivation through opting in to programs and self organised teams
  • Departments to be headed up by Agile+Lean thinkers to change the culture significantly

Corporate Reforms

  • Reform tax to influence spend on sustainable environment strategies. I know of an organisation in Australia that has 15000 employees and their spend on being sustainable is 0.5 FTE. It is abhorrent and needs fixing.
  • Reform tax to dampen usage of offshoring.
  • Dedicate funding to a Lean Startup incubator. Capital investment is almost impossible to get in Australia. I want to encourage new small business, but I am also conscious that the success rate of Lean Startups is only 3%.

Educational Reforms

Break the model of extrinsically motivated learning and the command and control pattern of teaching through:

  • Roll Agile and Lean thinking out to the teachers and headmasters of the schools
  • Support the growth of empowered learning where students can choose how they learn. There are many examples of schools successfully using a working model of this throughout the world

Other Policy

  • We need to listen to the world experts on how we can turn around global warming and start taking action right now. They have the answers and a hypothesis of what needs to be done. We need to begin work on the dramatic changes needed, though I suspect some of the corporate reforms would make a headway into it.
  • Support the front lines of hospitals. They do not have enough staff and financial support to exist in a sustainable manner.


What policies would you have in a Lean Agile Party that focuses on a new Australia?

Read Full Post »

In large enterprises where Agile is being scaled and huge transformation programs are in progress there seems to be a growing trend towards standardization. But what does this actually mean? What benefits can you get from standardizing within Agile transformations and where should you avoid standardization?


What would standardization look like?

All coaches throughout the organization use the same terminology and when they explain what the term means the interpretation is the same. Examples include being clear on the hierarchy and relationships between features, epics, user stories, themes, potentially removing some of these terms. Which terms should be used – MMFs? MVPs? What about Daily Scrum vs Standup vs Huddle? Sprints vs Iterations?

The benefits on standardizing terminology? 

From team to team the understanding and usage of language is the same. This means that management conversations are on a level playing field. It would also enable more consistent reporting.

The risks of standardizing terminology?

If Agile language is already established (and varied), then some people and teams will have to change. This would be frustrating for those impacted who are already trying hard to tackle the large change in language.

Roles and responsibilities

What would standardization look like?

  • A clear definition that is understood throughout the organization of the roles of  the Scrum Master vs the role of the Project Manager.
  • Whether the role of the Project Manager is still required or not.
  • The recognition that KPIs by role may need to change to align with responsibility changes.
  • A shift from “that’s not my role” mentality to “what do we need to achieve as a team” mentality, ie becoming more ‘T-shaped’. This would need to be a conscious choice to breakdown silo like behavior resulting in quite a significant mind shift.
  • Importantly, and often neglected, is the change in responsibilities for management – in all layers. Agile transformation isn’t about a change only at the grass roots, the shift needs to be throughout all layers of the organization.

The benefits of standardizing roles and responsibilities? 

A clear understanding of boundaries on roles is always going to be a good thing, you don’t want two different people doubling up on the same responsibility.

The risks?

That said, being too restrictive can be dangerous. How dangerous can depend on the culture – you want people to know what they should be doing but in an Agile environment there shouldn’t be an attitude of ‘That’s not my job.’ The mentality shift moves away from ‘me’ and ‘I’ including the fear ridden culture to one of ‘team’ and ‘what can I do to help the team to realize value even if it isn’t in my role’.

Deciding on what to do with Project Managers is a key decision that needs to be made in Agile transformations. Anyone who worked hard to get into a position of authority may have issues with the perception of a role shift being a downgrade – especially if you are going from being called a ‘Manager’ to a ‘Scrum Master’.

Logistically changing formal role descriptions, role descriptions that people were hired against, can be very challenging. It is a process that can take many months, requiring enterprise agreement changes and potentially trade unions. Most organizations avoid this and opt to not change the formal role descriptions, instead working with informal agreement changes.

Phases and governance

What would standardization look like? 

Whilst Scrum is often considered a lightweight Project Management method, when applied to organisations, and in particular large enterprise organisations, it often doesn’t scale up by itself. SAFe is a good example of an approach trying to solve this problem, but to a good extent SAFe doesn’t know your organisation. It doesn’t know the historical risks that you have had to tackle and the steps that you have taken to mitigate these risks from happening again. And while over the years these measure may have become stale, some of them are still useful even in an Agile and lightweight environment. These extra steps, steps like how you go about building a backlog, how you gain funding (when you haven’t yet shifted to beyond budgeting), how you manage your risks, they are steps that are really important to enterprise organisations.

You cannot fix everyone at once as an Enterprise Agile Transformation Coach, you will need to pick and choose your fights and in order to do this you will need to identify which parts of the existing governance model and process you want to shift.

Standardization here would be a guideline of:

  • How to build a backlog
  • How to kickoff new projects (including funding)
  • How to manage and escalate risks and roadblocks
  • How to incorporate security, UX, architecture and infrastructure into your work delivery practices; and
  • How the work will be overseen to ensure that continue/stop the line decisions can be made

The benefits of standardizing phases and governance? 

In some respects this is about senior level management feeling somewhat secure that the world hasn’t completely changed. That the toys haven’t been thrown out with the bathwater. Agile can change so much as a disruptive change model and consequently it scares the hell out of most managers because they no longer feel safe. It isn’t about feeling like they are still control, because we all know no one ever is in software delivery, it is about ensuring that organisational risks are mitigated, and that where possible complexity is dampened.

By having some framework in these areas it means as a coach you can tackle and target certain areas to focus and change and segment off portions to get to in the future.

The risks of standardizing phases and governance?

  • That we forget it was always about individuals and interactions over process and tools.  
  • That inefficient process just gets replicated again
  • That extra steps added in slow down delivery. Sometimes it isn’t about injecting process to ensure that a problem doesn’t re-occur, it is about knowing the cost of the problem and consciously making a call to accept this cost again in the future if it happens and hence avoid adding in process.

Visual management

What would standardization look like? 

  • Board flows are standardized for like work type teams – eg software development teams all have the same flow
  • The same metrics are displayed from team to team – eg Cumulative Flow Diagram, Release Burn Up, Mood charts, Feature usage and uptake analytics
  • Card colours no longer require a legend or a key as it is consistent from team to team – eg features are blue cards, stories are white cards, technical debt are yellow cards

The benefits of standardizing visualisation? 

  • You can short cut the time it takes to understand what the board is telling you, able to go from team to team and take in the work and what is happening with the work rather than trying to understand the board itself. Importantly who would want this? This would benefit coaches, managers and curious people who pass by, but to the team itself it would have limited benefits.
  • Training of important metrics and how the metrics are represented would cost less time.
  • Teams could be compared, but I believe this is a potential anti-pattern. You don’t want to encourage team improvements by comparison, you want to encourage improvements by focusing on the team’s metrics by themselves.
  • Procuring stationary becomes simplified

The risks of standardizing visualisation? 

  • Innovation and creativity associated with the visual management of the board is stifled
  • Consequently buy-in and motivation related to the method and/or the work is reduced
  • Team specific problems which could be resolved or managed through adaptive visual management strategies are not tackled – eg the need for expedites, the need to split work based on class of service, varying card colour for the purpose of making a particular series of stories pop, creative approaches to solving prioritisation issues in the backlog
  • Metrics of low value (but considered mandatory) are displayed when metrics of high value are not due to limited physical space available in the visual management zone.

These risks can be somewhat mitigated by a clear statement that standardisation of visual management is more a guideline (for those in the ‘shu’) and can be enhanced or modified based upon the needs of the work or team.

Estimation and sizing

What would standardization look like? 

  • An understanding of what method should be used to estimate stories and features – eg t-shirt sizes, Fibonacci sequence; and
  • What the boundaries of these are, for example, a story should never exceed a sprint, a feature should never exceed a release.
  • It may be worthwhile to go a little further and give a guideline that a 13 point story is potentially exceeding a sprint, or that a XXL is likely to have multiple releases.
  • At the extreme this would be clear cut – expressing features or stories in many different methods of relative and fixed:

XS – 1/2 sprint, 3 ideal dev days
S – 1 sprint, 6 ideal dev days
M – up to 2 sprints, 12 ideal dev days
….. and so on

The benefits of standardizing estimation and sizing? 

A common language and image is formed when sizes are used across multiple teams. Again this has significantly more benefit for managers  and coaches/trainers than the teams themselves, but if team members shift around (which really they shouldn’t) then at least they are already familiar with how to size and can hit the ground running. 

The risks of standardizing estimation and sizing? 

Estimates can be used as a weapon against teams. When the same model is used, it can then consequently be used to compare teams. I believe this is a very risky place to be and do not, under any circumstances, recommend comparing teams. That said, if you have this as a standard, a manager will always inevitably do this if they do not have a coach nearby. It is for this reason that I probably wouldn’t go the extreme and relate a relative value to a fixed period of time – it enables misuse and also doesn’t harness the power of relative estimation and how it naturally scales based on risk, uncertainty and historical delivery variability.


What would standardization look like? 

  • The same types of reports are generated from team to team and how the information is represented within them is consistent- for example, all teams must use a Cumulative Flow Diagram and a Release Burn Up Chart.
  • What metrics are reported, when, and under what circumstances is well understood.
  • Certain types of metrics may be generated for flow based teams, whereas fixed deadline teams may have different metrics that are required.
  • Quality realisation, employee engagement, customer satisfaction, feature build-measure-learn analytics, progress and risks are understood and consistently reported.

The benefits of standardizing reporting? 

Management can focus on asking the right questions rather than trying to understand what the graphs mean, consistency of training and education regarding reading information from teams.

The risks of standardizing reporting?

 Potential to compare teams, potential to ignore important data purely because it is not standardised.

Team size/composition

What would standardization look like?

 Team structures are setup for a defined ratio with a maximum limit to team size. For example 1 Product Owner : 4 Developers : 1 QA.

The benefits of standardizing team size/composition? 

Team sizes that are greater than 10 people are renowned for being sub-optimal due to the communication cost and risk of the Scrum Master being stretched too thinly to see the woods and the trees. Setting a limit so that this does not occur will benefit productivity and reduce risk. Establishing team ratio also ensures that certain specialities are not being overstretched.

Even better would be establishing feature teams that pull work to them rather than re-forming teams around work.

The risks of standardizing team size/composition? 

Not all work is the same, you could have a feature which is heavily test focussed that would not align well to the defined ratio. Balancing this can quickly become complex.

If the product requires significant enhancements with multiple feature teams working on it all at once, establishing a fixed ratio and size can help to scale up to the delivery problem, but multiple teams working at once on the same product introduces many other issues and complexity so a good approach to handling scaling up and communicating across teams needs to be introduced.

Cadence heartbeat

What would standardization look like? 

All teams use the same Sprint length and start and end the Sprint on the same day.

The benefits of standardizing a cadence heartbeat? 

When I say ‘this feature will be delivered in Sprint 14′ to a downstream dependent team, it means the same date to them as it does to me. Portfolio wall alignment is simplified, especially if you are using industrial tracking tools.

The risks of standardizing a cadence heartbeat? 

  • Teams who have been using Agile a while will be forced back to a Sprint number that they have already likely delivered to when the cadence reset is done
  • Getting meeting rooms for the first and last day of the Sprint can be incredibly difficult.
  • Agile coaches who are working with multiple teams will only be able to attend a maximum of four teams cadence activities on those two days before they get stretched too far, requiring a triage of ‘who needs the most help’ and potentially missing important content on those teams that were skipped due to scheduling conflicts.
  • Teams with higher levels of maturity are forced into a cadence block that may not be effective for them.

Standards to avoid

There are standards that should be avoided:

  • Target velocity for all teams (drives fudging of estimates to meet targets)
  • Restriction that you can only work on items in your flow state only
  • How long (fixed time) Inception should take
  • How long Sprint 0 should take
  • and probably many more but this blog post has gone on long enough


I have tried to present a somewhat non emotive opinion on the elements that I have seen standardized over the years. On a personal level I have felt very uncomfortable with vast amounts of standardization. I cannot really put my finger on why, but it may have to do with the fact that a lot of problems with teams I see have ‘it depends’ answers to them and require some creative thinking which gets constrained by the standards in place.

Maybe the word ‘standard’ is the biggest problem. ‘Guidelines’ have more wiggle room in them, and this may be a term that your audit group is not comfortable with.

As always, the key tenant is individuals and interactions over process and tools and a strong focus on removing waste – if you keep these as guiding principles then whatever standards or guidelines you put in place should not be too negatively impacting.

Read Full Post »

What is Agile?

The Agile RevolutionThis is a back to basics post driven from a number of interesting conversations I have had recently.

Firstly here is my personal definition of Agile:

An umbrella term for the toolbox of light-weight methods, practices and techniques that are focused on working smarter, not harder.

So let’s break that quote down.

“An umbrella term” means to me that it is encompassing, or arching loosely over something.

“toolbox” suggests that there are tools within it. Like all good tradies (that’s Australian for tradespeople) they know which is the right tool to apply to the right problem. You won’t use a hammer to tighten up a screw.

“light-weight” I debated whether to use this in the definition or not – primarily because to some extent I believe that Agile requires greater disciple than ever before, then again, you can still be disciplined and have simple tools in your box.

“methods, practices and techniques” Most believe that Agile is just either Scrum or FDD or XP, but you are rarely ever using just one method (or model) by itself and in reality you are likely to pick and choose the methods, models, practices and techniques that apply to both your organisation’s culture, to the system, to the people and to the situation.

For me a practice is a repeated activity – stand-ups are good example of this, as are retrospectives. The line between practice and technique is where it gets really interesting. Let me give two examples:

  1. Prioritise work
  2. Plan your ability to deliver based on facts

So we can prioritise work in many ways – we can prioritise based upon value, based upon risk, based upon both. We can use MoSCoW, High/Medium/Low, we can have ordered lists – the techniques that we use to get to a position whereby we have a prioritised set of work are quite varied.

We can also plan our ability to deliver based on facts in a number of ways – we can pull in an iteration worth of points based upon the velocity of the last iteration, we can measure average cycle time and understand our variations. Again the techniques to get the answers are varied.

In both instances we want to regularly ensure that we are prioritising work and that we are planning (where needed) based upon facts.

In this context it becomes simple to argue that maybe Retrospectives, as an example, are not actually a practice and more a technique. In this mindset the practice would be “Evolve the way you do your work” and the technique would be “Retrospectives”. I could live with that. There are many different formats that retrospectives come in – deltas, sailboat, quadrants, timelines. You can also evolve how you do your work in many other ways.

This then leads to the debate about whether statements like “prioritise work” and “evolve the way you do your work” are more principles than practices. Ultimately, if you are regularly doing something that reaches that outcome in a repeatable way I would say it is a practice. I am happy to debated otherwise on this front.

“working smarter and not harder”  Note what I don’t say in this definition – I don’t say that it is a software development approach. It can be used for software development, and works well for it, even was born from it, but it can be used for more – so why be exclusionary, spread the love! For this reason it isn’t about working software it is about working smarter. For me, working smarter means delivering value to customers in ways that have reduced waste, improved innovation and a very healthy respect for people.

So in conclusion – just to re-iterate, to me Agile does not mean Scrum. Scrum is just one single element of it. I like to think that methods, practices and techniques such as Kanban, Cynefin, Systems Thinking, Lean, Systemic Flow Mapping, etc all have a place in Agile.

Within Australia I have never seen us as an exclusionary crowd. We embrace better ways of working smarter. We like to absorb them into the Agile toolkit we have, a toolkit that should evolve and change over time as we better understand our world and what works and what does not. Most coaches I know don’t teach just one way, they teach a toolbox of ways and often subscribe to the Oath of Non-Allegiance. They have moved on from the Agile Manifesto and begun to embrace the MoreAgile Manifesto.

As always, all comments are welcome but I desperately desire feedback from the Australian Agile community – what do you think: are we embracers of evolutionary Agile or as a community we are stagnant?

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 »

This is more of a general FYI post then my usual subjective opinions. Firstly I want to mention the fun stuff – hopefully in the next few weeks you will see the number of contributors on this site grow. It was always my intent for this site to not be just my thoughts but also those that I respect but whom do not have an engine to contribute to. If you are also keen to contribute then please contact me directly.

Secondly I will be AFK from the end of the week for two weeks as I go on my first overseas holiday in six years I will also be attending #klrat in Austria.

Lastly I want to say with some sadness that whilst Craig and myself were very “The Agile Revolution” podcast happy when at Agile Australia unfortunately a number of casts have been relegated to the nether. We did a full podcast before Agile Australia that is lost and the first two podcasts we did – one with Ilan Goldstein and the other introducing our day has also not worked correctly (despite one of them being tested and playing back). The last cast done (with a new chip in it), has turned out and so that will be posted up tomorrow night.

So with the news all done, here are my thoughts on Agile Australia:

  • Amazing atmosphere. With 850 participants it wasn’t just buzzing it was flying with conversations. Walkways were packed (which made it a little frustrating to actually try and find someone), but breaking out downstairs for some quiet conversation was also great.
  • Fiona Wood was very surprisingly a brilliant Keynote speaker. I was incredibly dubious of how much worth I would get out of a non Agilist being first to talk to a jam-packed room but it occurred to me as she talked that she made the perfect keynote. This is because a keynote should be all about passion and a call to action and Fiona did just that. She re-inforced our Agile mindset through her discussion on collaboration, teamwork, passion, customer outcomes, striving for greatness rather than just good enough, knowing your weaknesses and staying in a positive mindset.
  • The next session opened up with Craig doing a funny sequence of slides on the history of Agile (including my take on the manifesto being written in a spa tub).
  • Michael Bromley’s presentation on hiring for agility was spot on and whilst I didn’t learn anything new I could see lightbulbs going off in people’s minds around me.
  • My panel itself went well but as per my last post we really didn’t get a lot of time for questions due to some overruns.
  • Ilan Goldstein was very good laying down the basics of Scrum Master. I had an Iteration Manager that I am working with sitting next to me in the session and he felt that it re-enforced a lot of concepts for him.
  • The most raved about presentors from the grapevine included: David Joyce, Dipesh Pala, James Ross and the Agile Board Hacks guys.

I haven’t covered all the sessions, predominantely because I spent quite a bit of time outside of sessions speaking with people one on one in the open space and breakout areas.

Themes that were very strong throughout the conference included:

  • Agile Governance (felt like it was covered through four presentations)
  • Agile Leadership (see above)
  • UX (see above)
  • Offshoring (covered through three presentations)

I am not saying the cross coverage is a bad thing, in fact in each instance there were different perspectives and I felt that helped to re-enforce messages. In some ways the program itself is probably the key reason why it reached 850 people – the topics were targetted this year less towards developers and more towards managers and executives.

I also want to take the opportunity to thank all the people that I talked to. Your words have made me wiser and I loved every minute of listening to them.

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers