Agile Forest

Find your path to agility with Renee Troughton

Korea

North Korean Innovation

 

A North Korean Architect was commissioned to draw a futuristic version of North Korea with zero limits on both financial feasibility or even

structural integrity.

The result? In what seems straight out of a 1963 ‘The Jetsons’ episode, the architect seemed to produce drawing after drawing stuck in an era of decades past. Simplistic treehouses, ancient decor and ordinary footbridges made up a few of the images created.

So why with such an open remit did the architect produce such backward thinking results? Maybe it was purely the individual, maybe they misunderstood the brief, or maybe this is a glimmer of what happens when innovation is stymied by a lack of injected ideas.

1963 Jetsons apartment

1963 Jetsons apartment

The secret to innovation isn’t just having the time to think freely, but also having a great depth of material to draw on. This architect was not influenced by decades of shifts and ideas in architecture.

So the next time you think that innovation is all about having 20% downtime or having hackathons, think about the learning culture you are creating instead. Are you creating a learning culture to enable innovation or are you just enabling the creation of more Jetsons apartments?

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

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

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

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

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

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

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

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.

Conclusion

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

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.

Conclusion

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

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?

Follow

Get every new post delivered to your Inbox.

Join 942 other followers