Agile Forest

Find your path to agility with Renee Troughton

COTS, SaaS and Agile

Renee Troughton

1 comment

August 13, 2012

With the rise of more and more organisations moving towards using Software as a Service (SaaS) and Commercial Off The Shelf (COTS) solutions for their product problems there is a gap in understanding about what Agile can offer in this space.

Most believe that Agile firmly just sits with the actual development of the product and stops there. Today, I will be arguing that there is more and will solely focus on the non product development aspects.

To do this I need to delve a little into the procurement process of choosing a product, but keep in mind that each organisation will have it’s own process. What I will describe is just a method, there will be others, but it is one approach.

So to start let’s go back to basics. You don’t just wake up one day and say “Hey let’s use Product X for our flagship Y!”, unless of course someone high up within your organisation got a free trip to a fab place by a vendor who remains nameless.  You likely have a core need for such a product/service. Maybe your existing system is on green screens. Maybe your business has changed so significantly that you current solution isn’t anywhere close to your needs. Whatever is the reason you need to be clear what the problem is you are solving before looking at what could solve it.

Once you understand your problem think about the needs of the product/service. These are your goals not your requirements.

I believe that it may be at this point in time that you first want to entertain the idea of a COTS/SaaS solution. Normally I believe this would be too early but if you are going down the path of not custom building a solution then you are essence entertaining the idea that you may be dramatically changing your business process model. Now, just as a point, I want to clarify that when I am talking about COTS or SaaS I am not talking about Google docs or GMail, I am talking about software that makes a difference to your business on a day to day basis. It could be a new accounting system or a complete HR package solution. In these instances it is likely that you already have a complicated set of business rules that is embedded to your culture. It is likely that the existing product is so tied to behaviour and process that where one ends and where the other begins is no longer understood.

When you choose to use a COTS or SaaS solution you throw away your business process and use the product/service’s process.

It might be important to you to understand the deviation between your current process versus the product/service’s process via a gap analysis so that you can work out the impact from a re-training perspective, but I believe that it is waste – regardless you will have to retrain or hopefully you will chose a solution that is so intuitive your seven year old could use it.

Next you need to understand your desires for the new product/service. These are your detailed desires – but they should not be thought of as requirements as it is highly unlikely that a single product or service will meet all of your desires.

Categorize your desires into three levels – absolutely critical (showstopper if product doesn’t have), would be elated if it had/did, would be nice if it had/did.

Do these sessions in the same way you would do all of your Agile work – in collaborate teams.

Kick-off your procurement process using the categorized desires as feeder items. Rate the products/services based upon these categorized desires. Naturally you will rate them on other procurement factors such as organisational stability, reputation, service levels, etc.

For the three products/services that score the highest on your ratings invite them into a collaborate workshop (not at the same time, separately). Run this in an Agile way and assess how much they are adaptable to the way you are working. Get them to help you break the desires down into real implementable stories. Estimate the stories with their help. Some stories will cost nothing to implement as it will work out of the box, but a lot of the stories will likely require some element of configuration or data gathering and analysis.  When you are estimating consider any interface implications, configuration, customization (strongly not recommended to do this), data gathering, data analysis, legal checks, policy checks and the number of stakeholders that you might need answers from.

Then with the product/service vendor also break down and estimate stories for training, communications, culture and business process change management, deployments, environments and extent of testing. If the provider will be offsite add in additional costs for communication (an additional 10% in accordance with the Thomas Allen curve).

Prioritise all the stories. You can now compare the plans and costs between each of the vendors with an understanding of the cost of the product/service itself. Chose a provider and continue with your procurement process.

When you start to write all these stories up it should become very obvious that implementing a COTS/SaaS solution isn’t as easy or cheap as expected. In fact, it is highly likely that the product/service itself is just 25% of the overall costs. This is something that the people with the buying power often overlook. It is everyone’s responsibility to make sure the real cost comes out and is understood.

Organisational Success Sliders: When Shareholder Value Isn’t Top Dog

Renee Troughton

no comments

August 2, 2012

In April 2002 Rob Thomsett released his successful book Radical Project Management. Contained within was a little gem known as Project Success Sliders.

In normal Project Management there is a well known term called ‘the Iron Triangle’. This triangle represents the three key facets that a Project Manager needs to normally watch like a hawk – the scope, the cost and the time. In non-Agile Project Management these three elements are commonly fixed. In Agile Project Management these elements are defined at the start of the project, however as circumstances change we want a trade-off to occur. If we can’t meet our initial proposed scope, cost, time and quality then something has to give.

Generally I don’t allow team satisfaction to be traded off, it goes directly against sustainable pace and good leadership. Similarly I don’t normally have stakeholder satisfaction because ultimately that is a gauge of the four elements (scope, cost, time and quality) at play.

So what Project Success Sliders allows you to do is have an upfront frank discussion to acknowledge that it is hard to meet all four elements and that if something has to give what is it? Not all four can be possibly fixed. One will always be the most flexible, one will always be the most fixed. Two will be somewhere in the middle. This is about a conversation to understand critical needs.

So why do I raise the subject of Project Success Sliders?

In organisations I believe there is a similar model at play. I call them, for lack of anything incredibly imaginative, Organisational Success Sliders. Rather than the slider elements at play being time, cost, scope and quality we instead have Shareholder Value, Employee Engagement, Customer Delight, Supplier/Partner Symbiosis and lastly Environmental/Ethical Responsibility. The first three should be fairly obvious. The last two might require some explanations – supplier/partner symbiosis is about a mutually beneficial relationship. It isn’t healthy to screw your suppliers value down to nothing. It results in a loose/loose situation. Environment/Ethical Responsibility is about being corporately responsible with the world. How much is an organisation investing in being sustainable? In being carbon neutral? In ensuring that its suppliers aren’t using child labour in China?

Most organisations have Organisational Success Sliders set to Shareholder Value fixed at priority 1. Employee Engagement and Customer Delight are in the 2/3 slots, usually with customers winning over employee satisfaction. Supplier/Partner Symbiosis and Environmental/Ethical Responsibility are both vying for the last spot as the most flexible.

I want organisations to think of more than just Shareholder Value. I want them to consciously choose whether to put Shareholders above and beyond all other elements. Should these elements really be prioritized? Probably not, but they are, so call it for what it is and make is clear where the priorities lie. Only through firstly making this constraint transparent do we free ourselves to question it.

Blue Ocean Strategy: Uncontested market space or innovative differentiation?

Renee Troughton

no comments

August 1, 2012

I had a considerable amount of trepidation when reading this book by W. Chan Kim and Renée Mauborgne. The title itself is ellusive and doesn’t lead the reader to understand the value that it might have for them. The subline is a bit more useful “How to Create Uncontested Market Space to Make the Competition Irrelevant”. A better byline would have been “Major differentiation through innovation”. You see, you will never make the market uncontested permanently. In today’s day and age competition is quick to catch up, maybe that wasn’t the case 7 years ago when this book was initially written.

I put what I had heard of this book aside and read it. Surprisingly for me, I enjoyed most of it. The first four chapters are what I would consider a must read for any manager, leader or product owner. Why? Because it fills a niche where there is a hole – how to create a differentiating and innovative business strategy for your products. It won’t guarantee that your strategy works. It won’t really help you execute your strategy either, but it is a sensible thought process for where strategic ideas could be lurking.

When I had finished reading Lean Startups for the first time my immediate thought after “this sounds like a great way to execute an idea” was “what idea should I execute?” This book gives you the tools to be able to seek such an idea within yourself. Blue Ocean Strategy is the Yin to Lean Startup’s Yang. Similar, but different. Each valuable, but together a powder keg.

So what is it exactly? Well despite what the authors will tell you, it is a strategy set of practices based upon a theory presented by the authors. The theory they have surmised after analysing numerous companies is that the only thing that makes a company successful is major differentiation through innovation (my words not theirs). All too often organisations spend an inordinate amount of time and money on catching up with other competitors or trying the win customers from the same pool. Blue Oceans (or as I like to call it innovative marketspaces) are about finding a new set of customers by differentiating in the market at a more macro rather than micro layer.

The book sets this up through a huge number of examples that clearly present their case. One of the key tools they use is a simple graph that anyone can use to describe their product and their product differentiating characteristics. Below is an generic example of such a graph. 

It should come as no surprise that Kim and Mauborgne are recommending finding out as much about your customer is imperative. But also that you should find out about all those people that are not your customers and why. By asking such questions you may gain insight and be able to differentiate to create a new customer segment. Their key suggestions for identifying innovative differentiation are:

  1. Identify cross industry opportunities
  2. Identify intra segment/industry opportunities
  3. Identify non familiar buyer potential
  4. Identify complimentary packaging opportunities
  5. Identify emotional appeal opportunities (Buyology does a better and more accurate job of describing how to do this)
  6. Exploit trends

Sounds sensible right? But real insight generally is sensible like this and they give excellent examples throughout to back it up. Most of the examples succeeded not because they used this strategy, and it should be noted that they have given no proof to their work nor were they able to recognise the success rate of innovation.

It made me think about the companies that I have worked for and the competitors that grabbed some of the marketshare. Certainly they found a characteristic, focussed on it and were rewarded. I could see some validation behind this.

Then I was curious about organisations that had actually used this and whether they have garnered success. Nintendo is known to be using it – Wii and 3DS were born and arguably they are having success. What is interesting is that as soon as a company creates differentiating innovations others will try and catch up – just look at Connect as an example. Another described project is the creation of the F-35 fighter jet. This jet was meant to be packaging intra segment opportunity – a navy, marine and airforce plane in one. The product characteristic graph for it is interesting but if you have a look at the project which is now eight years overdue and with a price tag of $1 trillion dollars you have to wonder whether it was worth it. Interestingly constant change of requirements has been labelled the cause for the blow out. So maybe the product charactistics were a too simplistic approach to the strategic problem?

But it did make me think about how this might apply to Agile. A graph could easily be made to demonstrate the differences between Agile and Waterfall. Similarly one for Scrum and Kanban. One can be created to define the opportunity that exists in the market. I have seen one done for managers and leaders – of what their current characteristics are versus what the strategy was to move them to it. It made me consider the Rightshifting proposition and the characteristics of the Analytic versus Synergistic mindset. 

This is a simplistic version of it, and no doubt I will have some (all?) elements wrong (read the 10% as low focus on and 90% as high focus on). Where can this graph be improved/corrected? What sort of things can we consider from a strategic perspective?

Lastly, whilst I do believe there is value in reading the book you should open yourself up to other thoughts in the community. The Blue Ocean Strategy has had many scathing reviews of it. Many of the points in the less than positive reviews I do feel are valid. Personally it is just another really simple tool that you can add to your toolbox. You won’t use it everyday, but one day you might need to take this tool out.

Sad Puppy Scrum Extentions

Renee Troughton

1 comment

July 18, 2012

I know that I am not always the biggest advocate for Scrum. It isn’t that I don’t believe that using it and other Agile techniques doesn’t work. I do believe that there is considerable value in Scrum. But if you read over my other Scrum posts you will understand that I don’t think Scrum has moved with the times nor sufficiently answered the handling of production defects problem.

You can imagine my joy when earlier this year Scrum proposed a framework to allow extensions.  I gave it some time, watching from the sidelines. In May I had a look over the three proposals. Admittedly I was disappointed with the three that got through (one implies an incorrect application of feature teams, another is a renamed practice directly taken from XP), but rather than focus on the negative I remained in hope that more would come that would hit the mark.

So when Scrum.org announced recently that they were stopping the Scrum Extensions program I felt like a sad puppy. I wanted to see this work. What I did really love about David Starr’s post on the Scrum Yahoo group was the lessons learnt:

  1. We confirmed the need is there.
  2. The mechanism we tried to service the need was not the right one. People found it hard to consume.
  3. Quality of several submissions was not sufficient.
  4. People unfamiliar with Scrum found the name confusing.
  5. There are many existing and potentially competing options out there. Agile Atlas looks promising, Agile Alliance resources, etc.
So we learned some things. And we’ll do better in the future. It would be cool to collaborate on this stuff instead of spooling up a new instance of a reference.

David set aside much ego and took the Scrum ethos of inspect and adapt. Arguably it is more a Lean Start-up perspective of measure, learn and pivot, but regardless I hope that Scrum.org continues to try and make something work.

Note: I thought using the term ‘retired’ or ‘deprecated’ was quite odd in reference to the suspension of Scrum Extensions. To have retired it implies a life long lived. To be deprecated shouldn’t it have been replaced by something?

Buyology (not Biology)

Renee Troughton

4 comments

July 15, 2012

Recommended by Bob Marshall in a few tweets I took Martin Lindstrom’s second book on marketing with me to Austria to read predominantly because it was the most lightweight book in my backlog at 218 pages. In retrospect this was probably a bad idea – mostly because for one the hyped up quotes on the back of the book such as Newsweek’s “A page-turner” was very true. I couldn’t put this book down I found it that engaging and interesting. Read over just two nights, its stories were entertaining, informative and eye opening.

I have no understanding of marketing (so perhaps Lindstrom’s first book Brand Sense would be good for me to read) but I found this book incredibly approachable. It laid the foundation of common marketers and the importance of brand creation and recognition. Then it got into the interesting stuff – the fact that for several decades marketers have had it wrong on a number of fronts. Lindstrom makes extensive use of f MRI and SSTs to get into the brains of us and find out what really drives us to buy or not. Anti-smoking marketing is mythbusted along with interesting stories on the powerhouses of Coke, Pepsi and Nokia.

The parallels between what value people perceive marketing has verses reality and how such similar stories are heard of Agile was often on my mind whilst reading this book. Some in the software industry propose that Agile is pseudoscience that isn’t backed up by fact. The truth is – some are and some aren’t and in some ways we need to get better at measuring what is working or not. I do believe that Agile works but I am not convinced of which elements do versus don’t. I still feel some Agile teams spend too much time in upfront planning. I still feel that empowerment seems to only go so far and that timeboxing to avoid interruptions only works in some environments. But these are feelings that aren’t backed up.

The most interesting chapter was one title “I say a little prayer”. In this chapter Lindstrom compared marketing with the ten pillars of religion – belonging, a clear vision, power over enemies, sensory appeal, storytelling, grandeur, evangelism, symbols, mystery and rituals. Whilst Lindstrom was explaining how marketing similarly had the same foundations I again could see the parallels with Agile.

In jest many (including myself) have referred to Agile as a religion. But here was a clear comparison model and that scared me a little.

Belonging

It is easy to see how belonging fits into agile. We create teams that work together to share a similar mission. Additionally we also have a few communities that we can belong to in a wider group.

Clear vision

The whole point of release planning, creating a backlog, sharing our understanding of the work and how big it is enables the creation of a clear vision. We want to work in an adaptive way and we know that things can change but having a big picture view is also important – just don’t spend too much time on it.

Power over enemies

Waterfall vs Agile debates anyone? 281 comments in a week for this HBR Waterfall v Agile debate shows that there is still a war on. Even religions have factional wars to differentiate themselves – sounds like internal Scrum vs Kanban wars too doesn’t it? Taking another’s rituals and terms and using them as your own also has parallels in the Agile world.

Sensory appeal

This is one of the key benefits of using Agile over other approaches. Post-it notes and system cards overload our visual sensors along with many other information radiators. Business environments generally discourage the touching elements between people, but there is tactile touching of cards on the wall. Communication is heavily used utilising our speech and listening skills. Even our sixth sense is used to estimate cards. The only sensor not used is smell… I smell an Agile opportunity!

Storytelling

I don’t really have to explain this one do I? User stories, user story maps, focussing questions, empathy maps, personas…

Grandeur

Saying a story wall is grandiose might be a bit of a stretch. Agile conferences can certainly be grandiose. Oh well, failed on this one… next?

Evangelism

This is one trait that has been attributed to many an Agile Coach. Do we as a community appear to reach out and secure new acolytes? I fear this is the key reason many associate Agile with religious zealotry.

Symbols

Unless you count Japanese characters of Kaizen and Kanban as symbols Agile doesn’t have a strong focus on iconic symbology. That said, there are a lot of terms that are specific to the Agile community (and branch communities) that to outsiders could have the same associations and intent behind symbology – stories, product owner, scrum master, MoSCoW, poker planning… the list is extensive.

Mystery

I like to think of this as the science vs people debate. Which Agile practices and methods work? Why do they work? What about them doesn’t work? But there is mystery in a different way – mystery in that requirements are to some extent unknown until we have had a conversation, mystery in that what we might deliver in the next month doesn’t match a current plan (adaptive change), mystery in each and every day when we have a Stand-up and we find out what is really happening inside of our system.

Rituals

Even Scrum labels the commonly recurring activities such as Iteration Planning, Daily Stand-ups, Retrospectives, etc as rituals. Add in some wine, bread and absolution and we might just have a religion on hand.

 

Whether you can see the parallels or not, Buyology is a damn good book and I would highly recommend it to anyone. Now, let me find a SST and a stand-up and get started measuring.

Value versus action focused conversations

Renee Troughton

no comments

July 6, 2012

Conversations are HardWhen my team gets together as a group of coaches it is always an interesting few days. I say this in complete honesty. I find the conversations stimulating. I find the group passion contagious.

But I know that some don’t find it that way. Sensing the frustration I asked a colleague what in particular they disliked. I was expecting them to say that they found the conversations were too much an argument and less a constructive debate. What I did find instead is that they were frustrated by the lack of actions after large blocks of conversations.

I likened the scenario to facilitating a Daily Standup. Sometimes in Daily Standups the conversation will get off the standard three questions. Often this will end quickly, but occasionally the conversation extends. I find that the balancing act that a Scrum Master or Iteration Manager has to perform one of the most intriguing and difficult aspects of the role. You want to get the value out of the discussion but you don’t want the majority to be bored. Some Scrum Masters offline the conversation too quickly and don’t consequently get the value out of the activity because the real problems and solutions aren’t coming out. Some take too long to offline the conversation and the standup consequently fails to meet expectations which either leads to thirty minute standups or the practise getting dropped because it isn’t perceived as valuable.

For me, if the conversation in the Daily Standup moves slightly away I will let it go for a little while but keep a close eye on the body language of those not involved in the discussion. I will also be constantly assessing in my head whether the conversation is progressing or is stalled. If it is stalled I will re-direct, but if it is moving forward and language indicates an acceptance of the discussion then I won’t halt it. I will be conscious of time. I will be conscious of relevance. Do all conversations have actions? No. Should they? I don’t believe so.

Sometimes conversations are about understanding and not actions. But they need to be valuable. A valuable conversation may result in actions or decisions. But a valuable conversation can be about a common understanding. Take a look at the ladder of inference. These discussions are about aligning beliefs. Unless we align beliefs then we cannot progress into the actionable state. Conversations may align beliefs and create actions, but action doesn’t have to be an immediate outcome for the conversation to be valuable. An action can be a long term change in behaviour as a result of a belief change.

To have changed beliefs is the harder activity to do. It takes longer and can appear to be going nowhere. It is like the tightrope you walk when you facilitate a Daily Standup. But investing in it is the only way that a team will align with a common purpose and truly own the change.

Kanban Leadership Retreat Takeaways

Renee Troughton

7 comments

June 27, 2012

I had a great meal last week. It was more like a feast really. It started lunchtime on Wednesday the 20th and went all the way through to just past lunchtime on Saturday the 23rd. I am referring to the mystically labelled #klrat or Kanban Leadership Retreat held in Mayrhofen, Austria.

Going into the event I am not quite sure exactly what I was going to expect and get out of attending. I knew that I would greatly appreciate the networking and socialisation with similar practisioners, trainers and transformationalists (and I was in no way disappointed, all expectations here were well and truly exceeded), but aside from that I went into the event thinking that there was little that I wouldn’t be aware of or know.

Boy was I wrong. The amount of talk specifically on Kanban was probably only about 30% (subjective). Agile took up about the other 30% and the other 40% were models and concepts – some of which I knew but many that I had heard of and were re-inforced (eg Cynefin, Right-Shifting, Situational Leadership, etc) but a lot I had only briefly ever touched on or never heard of.

So what I primarily wanted to do with this post – is tell you about everything that I either heard about and want to investigate/read further or resonated significantly with me. These were my takeaways:

“Kanban is like Buddhism. You are quite welcome to keep your other religions when you become a Buddhist.” David J Anderson.

Facilitated by Liz Keogh @lunivore

In addition to having a lot to look over I also wanted to go into the experience with an open mind that some of my beliefs are wrong and should be fundamentally challenged. These are the quotes from people that made me ponder for many hours after where I could have it wrong:

  • “If you start with a presumption of innocence you will get further” (with regards to change). Liz Keogh eg. “I observed you doing x, does that match your recollection of events?”
  • “How can we get <this> outcome for you?” Liz Keogh
  • “We assume as change agents that everyone wants quick results” Torbjörn (@drunkcod)
  • “One of the worst things we can do (as coaches) is make walls for teams” (either @drunkcod or @jaspersonnevelt, both of these gentlemen were letting the quotes fly freely)
  • Companies are shifting more and more away from jobs for life. Loyalty doesn’t exist anymore (sound familiar?). We can expect a dramatic shift to more community based loyalty and involvement within. “A lot of people I would call colleagues aren’t in the same organisation, they are in this community”. This will lead to a framework of 70:20:10 shifting even further into the social area of learning (eg to 65:30:5), twitter (and even the unconference itself) is a classic example of this growing.
  • People have to want to change.
  • Instead of ‘Minimum Viable Product’ think of it as a ‘Minimum Viable Experiment’
  • and the many amazing conversations with Lowell Lindstrom @lowelllindstrom who enlightened me to why Scrum is a rulebook again and why Agile should never be all encompassing or swallow up general professional capability.

I want to take this opportunity to thank David Anderson, Katrin Dietze (@thisismui) and Sigi for all of your hard work in making this such a successful event.

Austrian Midrospective

Renee Troughton

1 comment

June 13, 2012

I have an hour to kill in the Vienna hotel I am staying at so I thought I would take the opportunity to do a brain dump of what I have seen and done Agile (or technologically related) as a bit of a midrospective:

  • Telstra are evil. I tried to get my phone working with an Austrian SIM card and the phone is hard coded to not allow any other SIM card to work in it. Several internet searches have found that this is due to the way Telstra and Apple setup the phones.
  • Apple is evil. For some reason unbeknown to me apple products don’t work on 95% of WiFi connections here (including my hotel, which was one of the reasons why I choose it). There is nothing worse than watching my hubby surf at ease on his android and me being devoid of any interwebs.
  • Austrian keyboards are weird. The z and y are around the other way. Count how many ‘Y’s there are in this blog. Each one of them I typed a ‘z’ in originally. Many of the special keys are in different spots or work using the right Shift or Alt.
  • I am finding some intriguing parallels between the history of Vienna and Agile. When I get back home I will write a more detailed blog but in essence there is definately a theme of people who were considered revolutionaries, who were incredibly passionate and entreprenurial but were ostricized for most of their lives. How they dealt with it and the ethics that they had I found very inspirational.
  • I have just finished reading Buyology whilst here. Again I will probably blog about it but again found huge parallels to Agile and Lean Startups. If you haven’t read this book then get a copy – it is eye opening and highly educational.

Non Agile related:

  • Surprisingly there is very little sunshine in Summer (it has rained every day)
  • Nothing opens until generally 10am. This would not be an issue if I didn’t wake up at 6am every morning. On the upside most things are open till late at night.
  • I’m sleeping really well. Walking about 7 hours every day will do that for you.
  • I need to buy another memory card. I have been taking about 400 photos per day (and processing them back to 100 at night). Vienna is truly an incredibly beautiful city. If you love jaw dropping architecture every time you walk around a corner then this is a must see destination for you.

Agile Australia 2012 Wrap Up

Renee Troughton

2 comments

June 3, 2012

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

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

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

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

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

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

Themes that were very strong throughout the conference included:

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

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

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

Agile Governance – The new disinfectant

Renee Troughton

2 comments

June 1, 2012

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.

Contact Renee at:

Email  +61 (0) 468 558 916twitterlinkedinPhone

Create a free website or blog at WordPress.com.