Feeds:
Posts
Comments

Archive for August, 2012

7 things I hate about people that don’t know Agile

Posted in Agile, Agile Practices on August 27, 2012 | 23 Comments »

Last week Assembla posted the 7 things they hate about Agile.  Here is my take on their seven things I hate about people that hate Agile:

1) My cultural norms are not your cultural norms

Apparently according to Assembla everyone that does Agile is old.  Damn I have been doing Agile since I was 27. Apparently that means I am old. I hate that cultural norms are flouted as if they apply worldwide. In the southern hemisphere those following Agile are more likely to be under 40 than over 40.

2) see point 1

Assembla says that Agile is stagnated. Again, just because it has in your country doesn’t mean it is a worldwide norm (see last blog). I agree there is a risk that people want to do and not be Agile, but that has nothing to do with stagnation. I have argued many times on this blog that Scrum is stagnant, I won’t dispute that, but Agile !=Scrum. What Assembla is ultimately saying is that people aren’t learning of other approaches other than Scrum. Is it because they don’t want to, because they see little value in anything else or is it ignorance? I don’t know the answer, maybe Assembla does. When I think of this point it makes me ponder on why we replaced Waterfall with Agile in the first place – was it not because Waterfall failed to evolve and address the problem we were having. Where is it written that Agile must or cannot evolve? We are the community. We are the ones that encourage it’s evolution or not.

3) People that don’t value values

Assembla says that the values in the manifesto aren’t applicable. The examples that they provided were all of manufacturing or command and control environments. Last time I looked Agile was being used for knowledge work not manufacturing. Also Agile methods were used in WWII – in war rooms – where knowledge and innovation were critical. I agree that shared goals are important. I agree that if you can deliver your work and not have to talk to a single person (or even a customer) then values are not important, but I don’t know of anyone in software development that can get away with that excuse these days. You have to have values and goals when doing knowledge work. I am not saying the manifesto is perfect, hell I am enjoying the MoreAgile manifesto these days, but that doesn’t mean all values are useless.

4) People who don’t understand how complex it is to change command and control behavioural patterns

Assembla says that they hate the Scrum Master role and believe that SMs don’t do anything and need to get a real job. As someone that spends a lot of their time trying to re-wire behaviour away from command and control to enable environments where teams are empowered and autonomous I find this frankly insulting. We are taught to respect elders as children, to not talk back to authoritarian figures. Throughout our childhood and schooling we are constantly re-enforced with command and control messaging. And yet we know through many studies that empowered and autonomous teams are more productive and innovative. The Scrum Master is there to break down the old patterns and enable the team to do their job without interruptions. This isn’t something that happens overnight, it takes months of re-enforcement for neurological pathways to re-assert themselves to be the prime pathway. Does this mean that a Scrum Master role is full time – no! They will be helping to deliver when they have free time. They are just a normal in the person in the team who has chosen to step up.

5) People who think that Agile means you have to estimate/People who think that Agile means you don’t have to estimate

Assembla says… actually I am not sure if they are for or against estimating from their comments. Estimation really depends on the environment that you are in, the governance and financial models applied to get work started. Ideally work would be incrementally funded. Ideally all work would be broken down into roughly the same size. In this ideal Agile world estimation is not required (assuming you understand your cycle time or throughput of work items over a defined duration). If you don’t live in this ideal world you might need to estimate – at best a rough idea of the size of the project based upon relativity to other similar sized projects, at worst so you know your velocity if using Iterations.

6) People who assume a practice is 100% applicable 100% of the time and that common sense has no place

Assembla says that pairing all the time is not valuable and just to pair reviews. For me pairing for reviews is worst case scenario, it is a lag identification of problems. Would I recommend pairing all of the time – hell no! But if it was complicated business logic or a new architectural framework being implemented then I would recommend upfront pairing.  Pairing is about quality, reducing rework, cross skilling and engagement.

7) People that think just because it is hard that you shouldn’t strive for it

Assembla goes into some points about Scrum and it’s poorly formed ideas. The first is about co-location. I am not sure exactly what problem Assembla has with being in a work environment that is fun (what people don’t enjoy an odd game of Foosball?!?). I agree that co-location is much harder to do these days, but does that mean you shouldn’t strive for it? There are mixed benefits in this field – co-location provides reduced costs to communication (Thomas Allen curve), but conversely co-location decreases engagement (by 0.2% assuming you are instead working from home, still the figure is fairly negligible).

The second point Assembla makes on this is that cross functional teams are unachievable. In large organisations maybe, smaller ones less so, it depends on your environment. Again it doesn’t mean you shouldn’t strive for it. A cross functional team in the long term is more productive. The purpose of a cross functional team isn’t to reserve talent (where did that one come from?).

The third point Assembla makes is in regards to capacity changing weekly. Discipline is hard. Yes unplanned things happen but onboarding/offboarding project team members every week is a severely dysfunctional Agile team and if this is the norm your organisation has serious problems regardless of Agile. This is why most Agile environments are shifting to product rather than project teams – that way the capacity and capability is always there.

The fourth point Assembla makes is that bugs will come up as you work and these impact your ability to deliver to a plan. Again discipline is hard. If you choose to use iterations, then understand your metrics of how much this is impacting you and add it into your planning process. Alternatively use an iterationless method and allow production defects to be handled as expedites. Or even better build quality in and don’t get bugs in production.

Conclusion

If Assembla is changing its developers every week, has bugs as a frequent occurrence found within production environments (hinting at  lack of automated testing coverage and quality testing), has developers incapable of widening their capabilities, teams that are stagnant, old, without values and breathing each day in an innovationless command and control environment I am really not sure that I would give them my business.

And Assembla – if your response to this conclusion is “we don’t use Agile” then I’ll add my #8 hate:

8) People that hate on Agile who don’t even do it.

Read Full Post »

What is Agile?

Posted in Uncategorized on August 22, 2012 | 25 Comments »

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

Firstly here is my personal definition of Agile:

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

So let’s break that quote down.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read Full Post »

COTS, SaaS and Agile

Posted in Agile, Agile Elsewhere on August 13, 2012 | Leave a Comment »

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.

Read Full Post »

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

Posted in Agile, Agile Practices, Management, Stoos on August 2, 2012 | Leave a Comment »

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.

Read Full Post »

Blue Ocean Strategy: Uncontested market space or innovative differentiation?

Posted in Agile, Book Reviews, Lean Startup on August 1, 2012 | Leave a Comment »

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.

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 604 other followers