Is agile Alive? Dead? Misunderstood?

Lats Sunday, after reading multiple “Agile is Dead” articles, I posted this short update on linkedIn

screen-shot-2017-03-05-at-11-03-37

As you can see from the stats, in less than 7 days it has received a lot of attention (I am not an influencer and my updates generally do not receive such large feedback)

My contacts in linkedIn include a lot of Agile or Lean Coaches and as expected, initially the message got some positive comments. Soon after some agile detractors joined the conversation and made it much more interesting as generally feedback that comes from different perspectives enriches the conversation adding dimensions that sometimes cannot be expressed by a biased mind.

I noticed 3 interesting trends in the messages.

  1. When agile is not driven by technology, agile fails
  2. When agile is driven by technology and not the business stakeholders, agile fails
  3. Agile is only useful to deliver something nobody wants quickly

The first 2 are extremely interesting, in fact they say exactly the opposite thing but they both come to the same conclusion “agile is dead”. I read and reread those messages and then I saw it

If agile is driven by one part of the organisation, whichever it is, and trust is not built within the whole organisation, it will fail. Do it like this and agile is dead before you even start.

If you try to own something that will change your organisation and run with it, you better make sure you share your vision, your responsibilities and your success with the rest of the organisation. How do you expect people outside your little world to want to follow you in this difficult change if they don’t know, understand, own and help you change. Agile/lean transformations are not driven by a department, they are driven by the whole.

And the result might be that you even stop talking about departments and only talk about the whole.

Now on objection #3.

Agile is only useful to deliver something nobody wants quickly

I have seen this very often and honestly makes me sad. A lot of scrum implementations have a Product Owner that is seen as the heart of the product, the person that understands the vision of the product and that takes the responsibility to take the important decisions for the future of the product in regards to strategy, prioritization and so on.

If you look at it this way, you might think that the PO is a single point of failure, in fact what if he is not able to make good decisions, how about his bias, is he a dictator?

As an agile coach I make sure that any product owner that works with me will have the tools for making good decisions. He in fact will know how to manage flow using WIP limits, he will be aware and become proficient in UX techniques, he will learn how to monitor, gather and use feedback from his customers, he will understand the importance of small experiments, he will be aware of cost of delay and when prioritising his features and user stories will have access to many advanced prioritization techniques.

Being agile does not mean automatically ignoring lean startup, lean UX, research. No that is not being agile, that is being a scrum master after 2 days training.

 

Advertisements

The art of doing 1/15th of the work and getting earlier business outcomes

imagesIf you are an agile practitioner you are likely to have read the book “Scrum – The art of doing Twice the Work in Half the Time” from Jeff Sutherland. I am a fan of Jeff and I believe that what he has done for software development in the last 20 years is great.

I do have issues with the book’s title though.

That title is what makes people think that being agile means being able to go fast and deliver more stuff.

Is this what real agility is?  Let me tell you a story.

At a client of mine a couple of years ago, I was asked to coach a product team and help them with a new product they were starting to work on. I was excited about it and asked the product owner to meet for a coffee and initial chat.

He kindly agreed and told me: “before we meet, have a look at our requirements document so you will know what the topic is”. He also told me that a high level estimation had been done and that the product would take from 6 to 8 months based on one agile team and that there would be licensing costs associated with an automated scanning system we had to acquire.

Attached to the mail there was a document of about 50 pages with detailed workflows, low fidelity prototypes of the screens and quite a lot of explaining text. I skimmed through it looking for a description of the problem that the product was meant to resolve, but couldn’t find it.

I read and reread the document and I couldn’t find the original problem that the product had to resolve, it was not there.

When I met the product owner, after agreeing the weather was miserable (that’s how we start any conversation in Dublin regardless of the season) he started describing his solution. I let him explain to me the beautiful features to build and the amazing technologies we were going to use.

When he was finished, I asked him: Why are we building this?

The initial reaction (completely normal) was a defensive stand for his solution. When I probed more, it was clear that after having worked for so long on the product on his own he had forgotten the nature of the initial problem that triggered the decision to build this product.

Using the 5 WHYs technique, in about 10 minutes, we eventually got to the initial problem that we needed to resolve.

At this point the conversation became different.

I asked what he thought were the features we should prioritise to resolve the problem so that the customer could have something earlier than in 6-8 months. That triggered the interest in the PO that identified 5 features (about 30% of the total described in the document).

I then took each feature and asked him if it was necessary to resolve the problem we just identified. After another 10 minutes we agreed that 1 single feature, that accounted for about 1/15th of the initial solution, would resolve the customers problem. To avoid making the PO feel bad about having done so much unnecessary work, I told him that we would build the other features incrementally, and that it was a great success that he had identified a single feature that would be useful for the customer almost immediately.

We then agreed to identify outcomes of success for the full product and start measuring immediately as soon as we released the first feature.

These read something like:

“We will know we have succeeded when 30% of customers do X instead of Y” or

“We will know we have succeeded when we will have 40% less support calls related to problem X”

et cetera. I made sure the business outcomes were related to the initial problem, not any product.

What ended up happening is that we built the first feature in 2 weeks (opposed to 6-8 months) and the measurements told us that we had reached what we wanted already.earlierbusinessoutcomes

We never built the other 14 features, we stopped because the business outcomes we had set were reached.

And yes, you guessed, we didn’t have to buy the licenses for the automatic scanning system either.

As a coach, my mission in organisations is to guide teams and navigate problems, maximising value with minimum work. This is always welcome when meeting CTOs or CIOs because – most of the time – less work means lower costs and earlier delivery.

We did 1/15th of the work and got business outcomes earlier, a big improvement IMHO from “doing Twice the Work in Half the Time”, what do you think?

Why are we sprinting?

another-victory-for-cipo

A few weeks back I asked this question on a very popular Agile and Lean LinkedIn Group:

10 years ago not many companies delivered value every month and Scrum really helped the industry with the concept of sprint. People started thinking in terms of vertical slices of value rather than systems and started to deliver value often, it was a great step forward towards agility.

Today most shops do 2 weeks sprints and it is commonly accepted that smaller batches are better than larger ones as they are less risky and also allow for earlier benefit realisation.

I understand how the concept of sprint has helped the industry become more agile and lean, but, and there is a but.

Why have sprints today? Why create artificial deadlines? Why create a minimum batch size, be it one week, two weeks or whatever it is?

If I am a mature organisation, I probably have cut delivery transaction costs and have a good strategy for continuous delivery and I am able to release whenever I want with little effort and risk. Why can’t I release when I have value to deliver?

Can anybody give me a valid reason for having sprints?

The topic became popular with a total of 35 thumbs up and 85 comments (including my replies)

Reading the answers, I am not only more and more convinced that sprints are unnecessary and dangerous artificial deadlines, but I am starting to think that in some agile practitioners thinking, the scrum guide has replaced the true reasons for agility.

If you have better reasons why we should always sprint, please add them as a comment, I am still hopeful I have missed something and want to learn.

 

 

 

 

 

 

SCRUM, from failure to success

This is a description of what made our previously failing SCRUM team a success within our organization. The lessons learned through failure were as important as the final success.

Before the “Revolution”: Our organization had been going through a transition to SCRUM for around one year. In the process of transitioning we had delivered a couple of software projects. Such projects had been seen as a failure by our Product Owner (PO from now on) for not delivering business value, and by the development team for failing to deliver a quality product.

The goal: The software development department needed a big success to justify continuing the transition to SCRUM and we were all determined to deliver a great product to our customers to demonstrate how much we had learnt from our own previous failures. The PO was extremely sceptical about continuing with SCRUM and didn’t refrain from showing their feelings.

The Plan: One SCRUM team was created to work on “Project Revolution”. Our goal was to deliver in a short period of time quality software that would exceed customer’s expectations and drive them back to embracing agile development.

The Focus: For the very first time we religiously adhered to SCRUM practices, we focused our efforts on Software Quality practices and built a solid relationship between the development team and the Product-Owner.

How we did it: We engaged with the PO from day zero and we tried to infect him with our enthusiasm for software development and quality. Before the start of the projects we gave a demonstration of our Quality plans and new software development approach: Acceptance Test Driven Development.  The PO showed interest in our approach beyond our expectations; he was blown away by the power of the tests ubiquitous language and clearly understood its potential value. He was also reassured by the demonstration of the Software Quality infrastructure we had built to harness the development of our application and took large interest in how acceptance tests were run and results reported. The development team discovered that something that seemed initially only a technical matter was very valuable to our PO.

SCRUM framework was followed rigorously by everybody including the PO that in previous projects was somehow cut away from the core of the SCRUM team. This time we really started to discover SCRUM’s real benefits of fast feedback and continuous improvement. The ATDD approach gave great benefits by allowing front-loading the discussions over incomplete/ambiguous requirements at acceptance test creation (the very start of development). We discovered quickly how front-loading such discussions would on one hand slow down development but on the other hand would allow us to develop only once and only what was really required rather than get to the final product by continuously fixing defects. Having a large bed of acceptance and unit tests gave the development team the confidence of refactoring freely and we were able to see the positive in the fast feedback of our builds.

Transparency: A full transparency policy was adopted, we were all part of one team, there were no secrets among us.

Collaboration brings success: Slowly the PO started gaining confidence in our work and when at the demos he started saying things like “This is a fantastic job guys!” or even “You’ve done in a 2 weeks sprint what in the past we were used to getting in 3 months and at a level of quality that is not even comparable”. It’s easy to understand that when our PO started trusting us, we were able to go even one step further and propose our alternative solutions to him. While in the past such solutions were categorically refused and a command and control approach was used by the PO, we were now at a stage where full collaboration was the norm and feedback was working both ways.

Fun: The product was delivered in time with excellent level of quality, the products’ business value exceeded the PO original expectations and best of all we all had great fun in developing it.

Project Revolution was an amazing experience.

 

Industry: Credit Information

Project Scope: Credit Information Management System

Technology: Java (Spring), Tomcat, HTML, jQuery, SOAP, Oracle ESB

Tools: JUnit, Cucumber, Selenium, Crucible, Sonar, Jenkins, Maven