Feeds:
Posts
Comments

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?

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?

Terminology/languagelanguage

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.

Reporting

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

Conclusion

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.

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

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

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?

 

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

 

Follow

Get every new post delivered to your Inbox.

Join 845 other followers