Feeds:
Posts
Comments

Agile Governance – The new disinfectant

June 1, 2012 by Renee Troughton

Following up from my attendance at Agile Australia 2012 I wanted to provide a link to the slides and also a bit more depth of information. Unfortunately a few parts of the panel discussion overran and consequently a few things that I desperately wanted to say were unable to get out.

So firstly, for those that were unable to attend here are the slides:

Agile governance The New Disinfectant
View more PowerPoint from AgileRenee

A write-up of the panel can also be found in the mobile edition of the IT News.

I just want to take the opportunity to get across a few points that I didn’t get a chance to (or were slightly misunderstood):

  • Stop thinking of work as Project vs BAU. When you get to the root of who does the work often it involves the same people due to the shared service nature of organisational structures. You cannot possibly plan by looking at only part of your workload.
  • Everyone will game the system because everyone (rightly or wrongly) perceive governance to be a bad thing. You have to make sure that you consider paths of where people will game the system and either actively encourage it, gather data from it or find a way to shut gaming down in that area. For example, if your governance process categorizes projects that are < $100k as not requiring a certain level of delegation people will split the work down so that it is below $100k. Some organisations would consider this a bad form of gaming the system. I believe that if people can split the work down AND demonstrate benefits also split down then that is an excellent win for the organisation – because splitting it down has just reduced the risk of failure and enabled earlier delivery.
  • Understand prior to transforming your governance model what is broken vs what is working in the model. Understand the wait times, the sink holes, who the deliverables are for and why. For every answer you get apply some critical and root cause thinking to it.
  • Often processes and models get bloated because they are handling odd exceptions – especially exceptions of failed projects. Build a process that works for 80% of circumstances. Let the other 20% be handled by smart people.
  • RUN YOUR AGILE GOVERNANCE TRANSFORMATION AS AN AGILE PROJECT. You don’t have to do everything at once – incrementally deliver it. Once it is “in production” regularly retrospect it.
  • Who owns your governance process/model? Who is allowed to make changes to it? If your answer involves people that never do the activities involved inside of the process then you have just enacted an ivory tower PMO.

Additionally I wanted to talk about where I saw governance going in the future and what were its threats. Thankfully Martin Kearns must have read my mind and tackled part of that topic. But for my record here is my two cents – the biggest problem I see for governance groups going forward are Lean Startups.

People incorrectly think (like I did for a while) that Lean Startups are all about R & D or entreprenural internet corporations. Certainly it is what it was designed for but I have been having visibility that the concept goes wider. For me Lean Startups go back to what Agile really was meant to be about in the early days – delivering very rapidly, ideally each day, having the real customer involved and adapting to change when we find out that we got it wrong. All too often though we are delivering only once every two weeks or worst, several iterations because of perceived lack of “value” until it is 80% there. All too often we still have a Business Analyst as a proxy or a Product Owner that has never talked to a real customer in their life. When people realise that Lean Startups gives us an alternative model to give these back, people will be flocking to it.

Which brings us to the problem of how do you govern a Lean Startup? Think of it in terms of a normal project – usually you have a release date pegged, set budget, a backlog of scope and a clear definition of quality. In a Lean Startup you have a budget set only based upon a date. This date is the date under which your learning stops. If you don’t prove that you are learning then you are unlikely to get another drop of money. Incremental funding is core to Lean Startups – how does that usually work with our fixed capital financial year funds? It means you consider your capital spend a pot of money. Each time you approve another incremental drop of money to a Lean Startup you get your ladel and scoop out a bit of soup. You need to make sure you spend that pot wisely.

So what do Governance groups govern in Lean Startups? They govern learning:

  • Has the team learnt anything about Customer Value since we last saw them?
  • Has the team learnt anything about their planned growth model since we last saw them?
  • Has the team learnt anything about the way in which we can expect a return of investment (revenue)?
  • Are they learning fast enough? How fast are hypotheses being tested?
  • Do the hypotheses make sense given the data?

When I mean learning it doesn’t have to be good news – it just needs to be either validated or invalidated hypotheses.

Most governance models govern scope, time, cost and quality. How many ask the question “Are customers getting value from this product?”. How many organisations are any good at benefits realisation? We spend so much time in governance at getting better at delivering. We need to spend more time getting better at delivering the right thing.

Posted in Agile, Agile Elsewhere, Governance, Lean Startup, PMOs | 1 Comment »

The biggest failure mode of management today: Listening

May 23, 2012 by Renee Troughton

For a while now I have been discombombulated. The cause of my confusion and desperation has been around the issue of management. 

I am not talking about Leadership. Leaders are people (whether in a position of hierarchy or not) that naturally foster an environment of collaboration, understanding and consensus. No, what I am talking about is the ability to influence creatively or constructively criticise the status quo to a person considered your “superior”. I want to use the term superior loosely knowing how much people will hate it, to represent an authority figure in a command and control environment. After all, Managers who aren’t getting the message about Leadership really do think they are superior (how many sweeping generalisations can I put in one post?).

I have come to the conclusion that a good number of employee frustrations are systemic from the culture; a culture which is powered by management. It is incredibly difficult to change culture from the bottom up. It can be influenced from the bottom up but there is a point where it cannot stretch anymore without management buy-in to the culture change. Failing senior management or C-suite buy-in to seriously throw money into changing a culture (yes culture change costs currency) I have been pondering how it may ever be possible for this problem to fixed in any way.

The C-suite don’t get it. Either they weren’t educated in it, don’t want to be educated in it or are too busy improving shareholder value. They are the Lords of this day and age, and how much did the Lords ever care about their serfs? Middle management are the Courtiers. Lower management are the cooks. Everyone else is working in the field.

Groups like STOOS believe that they can solve this problem through conferences targeted to the C-suite.  It is an interesting approach, but the sort of C-suite executives that will attend are the ones that I think for the most part are already on the journey or starting to question their belief system. It will make some in roads but I fear it won’t cross the chasm and I desperately ache for this chasm to be crossed. More needs to be done.

Others believe that they need to be right-shifted. I am admittedly still looking into this but have yet to get into significant enough depth to see if there is a mechanism to induce the chasm crossing.

I have been relaying this story a lot recently -

When a new person joins your team watch them closely. Watch how they learn and what they say. Watch how people react to what they say. Start to gather a pattern. What you will find is that when people join an organisation they are highly motivated. This is called the “Honeymoon phase”. The organisation is a veritible field of endless possibilities. They have been sold a dream by a HR department and manager.

The new person will listen for a while, enveloping themselves in the culture, trying to best see where they fit. They will start critically thinking early. They will ask questions like “Why do you do <insert task> that way?” They are trying to frame the task around their mind-map of how they have done it before and are judging it for efficiency and common sense. Failing a suitable answer they will delve further. Naturally they will gravitate towards the 5-whys, despite never hearing of Lean.

Eventually their critical thinking will be blocked by the “Monkey and the Banana syndrome” response. A root cause is not met and the first brick on the wall of critical thinking resistance is placed. As their first few weeks progress the same scenarios occur. Their brick wall begins to get higher.

When the wall reaches their knees self doubt sets in. Naturally they try to fight it, but in a different way. Rather than taking a critical thinking approach they will try a different tact. They will try the innovation path – providing suggestions of how they have seen it done elsewhere and the benefits that they had in doing it that way. They will get more Monkey and Banana syndrome responses or “We have tried that before, it didn’t work because <x> and <y>”, then the new person is back to the same lack of response to critical thinking. Innovation bricks now get added to the pile that is up to their knees.

After a few months their wall is up to their eyes and they can no longer see over the wall. There is no vision. No hope. The organisations culture is now embedded in them.

Sometimes I am asked what the Monkey and Banana syndrome is (usually younger people who haven’t heard it before). For those unfamiliar with it this is how it was told to me about fifteen years ago. I haven’t ever read the internet version so it may be a little different for those that have read it:

This is a story based upon a scientific experiment. A scientist puts into a large white room a metal ladder with a finger of bananas hanging from the ceiling. The middle step of the ladder is rigged to set an electric shock through the metal floor of the room. The scientist then lets in five monkeys. The monkeys excitedly see the bananas. One scrambles up the ladder and gets to the middle step. An electric shock is sent through the floor and ladder with all monkeys get shocked. The second time the monkey hits the middle step the other monkeys begin to get the picture. On the third attempt the monkeys pull the hopeful monkey on the ladder down and beat him up.

Subsequent attempts to climb the ladder result in beatings. The scientist then takes out one monkey and replaces them with a brand new monkey. This monkey sees the bananas and proceeds towards the ladder. He only gets two steps up before he is pulled down and beaten. He never knows why but after the second attempt he knows that if he tries to get up the ladder his peers will exert physical pressure.

The scientist continues to rotate the original set of monkeys out one by one and replace them with new monkeys. Eventually the room is filled of monkeys that have no understanding about why they are not allowed up the ladder but that if someone ever tries they should be beaten up.

“That’s just the way we have always done it around here.”

So you can see by my thought process that unlike some other thought leaders, I actually don’t think the ability to critically think is a lost art despite many years of behavioural conditioning supposedly beating this out of us. I believe critical thinking is a subconscious ability that we all have and continue to have despite command and control overriding it almost every single day. It is there. We have just given up trying to use it because no one is listening.

To get out of this endless rut I see a few possible solutions:

  1. Managers get better listening skills. Right now that you are done laughing, what are the other options.
  2. People get better persuasion and communication skills. On a scale of 1 to 10, 1 being highly unlikely to work and 10 being certain to work I probably rate this a 3.
  3. Have scientific metrics that prove empowerment, innovation and critical thinking are advantagous to the bottom line of an organisation. I am pretty sure the information is out there, but this depends on solution 1, and well, there goes that idea.
  4. Revolt. This is essentially option 2 but done on a less individualistic scale and more ganging up. This does happen naturally in teams but this method seeks pre-emptive goal setting. Despite being able to do this it will only work for one level above the team and from there will fizzle to get any traction, unless you get many teams to revolt at once and that is getting beyond the realm of possibility. Someone suggested to me that as an analogy it is like the monkeys ignoring the ladder and hopping on top of each other to form a monkey pyramid to get to the bananas.
  5. Teams get better facilitation skills and all team sessions have a pre-set, well skilled facilitator. In a team environment I give this a 5 to work, but outside of a team environment we are back to the original problem. That said you could encourage an environment where all suggestions of process change and innovation are raised through a facilitated team environment (sounds very Agile doesn’t it?)
  6. Enable a way to give a singular voice a pedastal. I am toying with an approach for this. I don’t think this will realistically happen inside of an organisation but I wonder if there is a means to force more social pressure for the C-suite to change their belief system.

What do you think? Are there other options to open up the eyes and ears of management?

Posted in Agile, Culture, Management, Motivation, Stoos | Leave a Comment »

Variability with resources and Agile

May 21, 2012 by Renee Troughton

It all started with a problem with the way we were doing software development. Projects took years with “phases” such as Requirements, Design, Development and System Testing taking six months each. We used to create thud factors where our value was determined by how much the table shook as we laid down our documents that we laboured over for hours on end. There had to be a better way, and as it turns out, there was: Agile.

People often talk about how Agile has failed or not solved anything. But even if Agile had not come along the world of software development would have had to have changed. In a market when speed is important, in a market where delighting the customer has a direct impact on sales, we would have had no other choice then to look at solutions such as continuous deployment, automation and suped-up customer collaboration.

But Agile didn’t solve everything. Some teams found it incredibly draining to apply it to their environment. They described it as trying to fit a square peg into a round hole. They were teams that had large backlogs of work not a “project”, they were not date driven and sometimes they had specialisation. In essence they were operational or maintenance teams. So they sought other approaches that would suit their needs, methods that were more supple to their workflow but still had elements of agility. And they found Kanban.

There are still teams doing work who haven’t had their problems solved. These teams have a different problem again. They have a set date for an outcome to be delivered, high specialisation or domain specific knowledge and variable demand based upon the stage and breakdown of the work.  This doesn’t normally happen in small organisations. This is a problem for large to massive enterprises. Neither textbook Agile nor textbook Kanban fit well in these teams. Primarily this is due to the fact that a stable velocity or lead time cannot be achieved – simply put, the team is too variable. The variability of the team changes based upon the story being delivered.

Let’s take a look at the work for such a team:

  1. Feature A
    Story 1, Priority 8, RPSI (P – Fred Flintstone, S – Barney Rubble, Bam Bam, Ken, R – Bam Bam, I – The boss)
    Story 2, Priority 6, RPSI (P – Fred Flintstone, S – Wilma Flintstone, Betty Rubble, R -,  I – The boss)
    Story 3, Priority 1, RPSI (P – Fred Flintstone, S – , R -, I – Betty Rubble)
  2. Feature B
    Story 4, Priority 2, RPSI (P – Barbie, S – Ken, R – Ken, I – Matel)
    Story 5, Priority 3, RPSI (P – Barbie, S -, R – Ken, I – )
    Story 6, Priority 5 (P – Ken, S – Fred Flintstone, Bam Bam, R – Bam Bam, I – )
    Story 7, Priority 9 (P – Barbie, S -, R – Barbie, I -)
  3. Feature C
    Story 8, Priority 4, RPSI (P – Ken, S – Betty Rubble, R – Betty Rubble, I – Bedrock)
    Story 9, Priority 7, RPSI (P – George Jetson, S – Barbie, Betty Rubble, R – The Thunderbirds, I – )
  4. etc etc

You will notice that there is an attribute attributed to each story that normally isn’t there for Agile work. This is a modified version of a RACI and RAPSI, which is a roles model for processes and activities and a role model for deliverables respectively. The example above predominantely uses the RAPSI model, but some work would benefit from the RACI more. A RAPSI normally stands for “Reviewers”, “Approvers”, “Providers”, “Supporters” and “Informed”. The provider is really the owner of the story, the person accountable. Supporters help the generation by answering questions and providing input. Informed receive the output but for information purposes; sometimes people believe this means they are the end consumers but that is not the intent. The “Approver” has been taken out as it isn’t the intent of an agile process to have heavy approvals – the assumption is reviewed is enough.

Some stories don’t have corresponding names against the roles. That is fine as long as consideration has gone into whether such a person(s) exists and why this story doesn’t require such roles.

It could be argued – when is a team no longer a team? But despite this the work needs to be done and the team does need to collaborate – not on a daily basis possibly, but on a story basis.

Trying to plan for this variability of when certain people are needed in the team could be potentially chaotic. If we tried to work in priority order and ensured that all of the cards were roughly the same size how could we potentially plan out resource needs in advance? The simplest solution is to give a weighting to the RPSI elements. As an example Providers would be ’4′, Reviewers would be ’1′, Supporters would be ’2′ and Informed is ’0′. Lets look at the resource usage for the first five cards in priority:

  • Fred Flintstone 6
  • Barney Rubble 0
  • Wilma Flintstone 0
  • Betty Rubble 3
  • Barbie 8
  • Ken 12
  • Bam Bam 3
  • The Thunderbirds 0
  • The boss 0
  • Matel 0
  • Bedrock 0

So Ken is very heavily focussed at the start of the work, despite being the provider of only two cards. We are hardly using Betty, and not using Barney or Wilma at all. If the team takes the assumption that there is a maximum threshold for a person and that value is 12 for any person for a week then this week is full and no more should be pushed into the weekly plan. So what does this mean for the under-utilised team members? Surely they would go back to doing their other work until the project is ready to pull them?

What has this method done – it has taken into consideration the constraints of the team, the constraints of the story and created a framework to plan week by week without ever having to estimate. It considers the maximum limit of the team and the variability of how they may be involved in a day to day basis. What it doesn’t do too well is drive for efficiency and assumes that lighter or dead time is spent elsewhere.

This approach could be called “VSM” or Variable Systems Method, but someone else took that acronym. It is a different method for a different problem. The Variable Resource Method.

Disclaimer: This is not a method I have been using on software teams, but it is a method I have had to entertain for Agile in the Business. Your weakest link is your busiest resource.

Posted in Agile, Agile Elsewhere, Agile Practices, Kanban | Leave a Comment »

Defeating raid bosses is like a Lean Startup

May 10, 2012 by Renee Troughton

When massive multiplayer online gamers work together as a team (called “Raids”) to defeat fantasy targets (called “Bosses”) they are repeatedly performing the steps of a Lean Startup – Build, Measure and Learn.

For raiders, “build” is working together to achieve the desired outcome of defeating the boss. They have a meta hypothesis – that the boss can in fact be killed and that once killed an item of superior value will be earned by one or more of the raid members. In the Lean Startup world there is also a meta hypothesis – that you can make a revenue generating business. In both cases it is possible to fail at this meta-hypothesis and disband the team never to try again.

But the incremental hypotheses is where it gets really interesting. Raid teams generally know how to operate together as a group. They have their own specialised roles. Additionally some people are able to be multi-disciplinary and can take on the roles of others. When first placed against a boss (who in business terms is a potential revenue generating customer) they will be armed with an initial hypothesis. It may be something as simple as what is called “tank and spank”. In a gaming world this means taking a standard stance of having one person taking the bosses attention, a few healers helping top him up and the rest of the team doing damage to take the boss down. In a Lean Startup world this would be starting off with a homepage and seeing who rocks up to the site and seeing what areas of interest they click on. For a very easy boss (or customer who has infinite time and interests) this might be a suitable strategy, but for a majority it will fail. What it will tell you though is some very basic information, potentially enough to start a new hypothesis.

You may have learnt that it will require another specialised “tank” role or that you need to reposition the team. In Lean Startup terms this would be a feature potentially being searched for very often but not implemented yet. This new hypothesis is then implemented. The team look at the results of their work. They use observation and actual data to determine where to improve and what to try next. Actual data for raids is obtained through tools such as combat logs and parsers that aggregate and display graphs of what is happening as the fight, or user experience across multiple customers for Lean Startups, is occurring.

For raiding teams it can take dozens of hypotheses before they defeat a boss. It takes a lot of analysing the data and re-execution of the fight in order to know whether you are on the right track or not. Teams may have a strategy built on multiple hypotheses that will consistently get the boss to 10 or 15% but never go past that amount. Ultimately they haven’t crossed the chasm. It is at this point in time that the team will need to pivot, drop their strategy and a large number of hypotheses and take a completely different tack. Only then is it possible to succeed. This is a very hard thing for a raid team to do. They have been pushing this set of hypotheses now for several hours. There is emotional attachment to the strategy. There is blame. There is tiredness. To change is hard when so much has been invested.

But if they do change, and they do succeed the rewards are sweet. There is a pride in having achieved the outcome and finally getting the hypotheses realised.

Interestingly raiding isn’t for everyone who games. The effort of having to work together as a team, of almost constantly being defeated, of looking at the metrics and not having a clue what tactic to take next – these are things that a lot of people just don’t have the guts for. They would rather sit on easy street and take on items that are immediately achievable, they don’t have an element of failure. That is fine, small risk reveals small rewards. For those that want to take risks there is the chance of bigger rewards.

Thinking you are suited to kickoff a Lean Startup? Maybe you should take on raiding within online multiple games and see whether you have the drive, committment and guts to keep failing before succeeding.

Posted in Agile, Lean Startup, MMORPGs vs Agile | Leave a Comment »

Gamification Wrap Up in Agile

May 2, 2012 by Renee Troughton

I wrote a little while ago about Gamification in Software Development and how it relates to Agile.Planning poker

Within that blog I said that I would get back to explaining Achievements more. And so here it is. Well, actually there it is.

When I originally started to write about Achievements and just how powerful they are in instrumental cultural change for Agile I realised that it wasn’t going to be short and wanted to promote it further. I asked Peter from Agile Scout if he was interested in publishing it and gratefully he said yes. Then as I wrote it I wanted for it to last longer in prosperity and consequently turned it into a whitepaper which you can download from the site.

And whilst we are on the topic of software and Gamification I recently found this thrilling TED talk (a few years old).

Posted in Agile, Games | Leave a Comment »

Moneyball quotes

April 26, 2012 by Renee Troughton

Moneyball has been credited within the Lean Startup community as a classic example of some of their principles.

I thought for those who haven’t had an opportunity to watch it that I would note some of the more powerful statements made in the movie. Some are slightly modified to apply outside of baseball so that you can potentially better relate it to your own environment:

  • The first guy through the wall always gets bloody.
  • This is threatening not just their business, this is threatening their livelihood. It’s threatening their jobs, it’s threatening the way that they do things.
    And every time that happens, whether it is a government, or the way they do their business, or whatever it is, the people that are holding the reigns – their hands on the switch, they go bat shit crazy.
  • Anyone that’s not changing – they’re dinosaurs.
  • There is an epidemic failure in the system to understand what is really happening. This leads people who run their teams to mis-manage their teams.
  • They are asking all the wrong questions. If I say it to someone I am ostracized. I’m a leper.

Posted in Agile, Agile Elsewhere, Lean Startup, Management, Stoos | Leave a Comment »

Product development is not the same as software development

April 25, 2012 by Renee Troughton

There is a growing trend within the Scrum community that believe when they are doing software development that it is actually product development. This is not the case. Software development is subset of work that is needed to be done to support product development.

In small organizations the deviation between software and product development might be small but the greater in magnitude an organization, generally gets the wider the difference gets. 

Scrum believes that you must have a cross-functional team that can get the Story/Task to “done”. Commonly this means that the team has the skills to be able to start the card with a meaningful conversation, develop it, test it, and deploy it. Often this results in Storywalls/Taskboards having headings like “Sprint Backlog”, “Analyse”, “Build”, “Test”, “Done”.

But what a lot of teams forget is that the software is only a smaller part of the organizational whole. Lets take a look other non-software components that are often involved in large scale product development:

  • Legal
    Sign-off of publicly exposed content to ensure that the organization is not opening itself up to liability; xtra-product only
  • Marketing & Sales
    Promotions of campaigns related to the product; xtra-product only
  • Training
    How users will use the product to perform their job; more commonly intra-product only
  • Communication/Change Management
    How impacted stakeholders and users of the product will be informed of what is happening with the product development and rollout; more commonly intra-product only

             xtra-product denotes a product that is sold to the public; intra-product denotes a product that is internally used within the organization

It is for this reason that I think Scrum’s label “Product Owner” is poorly named, or maybe more importantly has two few responsibilities associated with it. How many Product Owners have you met that have also taken on either the work listed above or the co-ordination of the above effort. They should. But if they did that and their standard Scrum duties they would be severely overburdened.

The cost of these extra activities are often just as large as the software development itself. Sometimes more, especially for COTS/Software as a Service implementations. Do you have Stories or Tasks in your Release Backlog for these activities? Why not? They have to be done and if are not aligned with the work that the software team are delivering then you are potentially opening yourself up to benefits realization risk. It’s all well and good to have the software on time, but if the change team haven’t been kept in the loop regarding when you plan on delivering minimal marketable features then they might be communicating that you are delivering them earlier than expected. Sometimes the success or failure of a product is never down to the software itself but how it was communicated and “sold to” someone; or how well they were trained in it.

How do you know that these other components are on track? Shouldn’t their work related to the product be fully visible and flow through from Sprint to Sprint?

If your product requires any of the above think about how you can incorporate them more into your environment and more importantly into your flow. Should the story/task be “done” if it hasn’t passed through these flow states. It doesn’t have to mean that every single story or task has to go to legal or through to training but it is a trigger – “will the training material need to be updated to reflect these changes?” If not, move it to done, otherwise wait until the necessary changes have been made before shifting it to done.

Posted in Agile, Scrum | Leave a Comment »

Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 322 other followers