Barriers to Agile Adoption

This post is from leadingagile.com by Derek Huether.

We’ve all seen it happen. Though we try to show organizations the benefits of using a mature agile delivery framework, we still run into roadblocks. Though the status quo is killing their organization, some barriers to further Agile adoption happen way too often among organizations that need it most.  I recently had a client ask me to introduce the elephant in the room.  I was asked to actually list some common barriers others have dealt with. I want to thank our friends over at Versionone for distributing an annual survey of the Agile space.  One of the questions?  What is preventing you from further agile adoption?  Within the last published survey, 4048 people responded and they were able to vote for more than one barrier.  The responses may sound familiar.

Click here to see the full post.

Posted in Agile | Comments Off on Barriers to Agile Adoption

Adaptive Leadership eBook Just Published!

This post is from jimhighsmith.com by Jim Highsmith.

My new eBook, Adaptive Leadership: Accelerating Enterprise Agility is out!

We are at a tipping point. Technology—cloud, big data, mobility, social media—tops CEO’s list of concerns per a recent IBM study. “There has been no other point in history when so many aspects of disruptive change have collided and conspired to wreak havoc,” writes retail prophet Doug Stephens. Companies that emerge successfully from this havoc will need to build agility into the very fabric of their organizations and develop the technological savvy to enable that agility. Adaptive Leadership provides a framework for such a transformation.

Over the past couple of years, I’ve been thinking, writing, and speaking about issues of adaptive/agile leadership and organizational transformations. The agile movement has greatly impacted software development over the last decade since the Agile Manifesto was signed. The two underlying themes of the agile movement have been reasonably successful (there’s always progress to be made)—namely, building better software and increasing satisfaction (and fun) at work. In a growing number of companies, agile/Lean values and practices have been infused throughout the organization, although there remain too few of these pioneers.

Click here to see the full post.

Posted in Agile | Comments Off on Adaptive Leadership eBook Just Published!

The Purpose of Measuring Cycle Times

I recently made the assumption that I did not need to explain why shorter cycle times were generally desirable.  However, I was mistaken, so let me explain:

If the average cycle time from starting to finishing a user story goes from 20 days down to 5 days:

Does this mean that the developers are writing code 4 times faster?    NO

understanding-cycle-times-01

 

Does this mean the customer is getting 4 times more features delivered?    NO

understanding-cycle-times-02

 

 

 

 

So what does it mean?

understanding-cycle-times-03

It means:

 

  • we can see meaningful progress 4 times faster
  • we deliver something 4 times more often
  • we are seeing problems in our end-to-end process 4 times faster
  • we are probably able to predict 4 times more accurately
  • we practise all of our end-to-end processes 4 times more and so have 4 times more chance of getting better at them
  • our focus is 4 times better and so our effort is 4 times more likely not to be wasted
  • we are working 4 times smarter!

 

 

Posted in Agile, Kanban, Scrum | Comments Off on The Purpose of Measuring Cycle Times

Sinn der Messung Zykluszeiten

Wenn die durchschnittliche Zykluszeit von Start bis zum Ende einer User Story von 20 Tage auf 5 Tage reduziert wurde:

Bedeutet dies, dass die Entwickler den Code 4 mal schneller schreiben? NEIN

understanding-cycle-times-01

 

Bedeutet es, dass der Kunde 4 mal mehr Features bekommt? NEIN

understanding-cycle-times-02

 

 

 

 

Also, was bedeutet es?

understanding-cycle-times-03

Es bedeutet, dass:

 

  • wir sinnvolle Fortschritte 4 mal schneller sehen können
  • wir etwas 4 mal häufiger liefern
  • wir Probleme in unserer End-to-End-Prozess 4 mal schneller sehen können
  • wir 4 mal genauer vorhersagen können
  • wir alle unsere End-to-End-Prozesse 4 mal mehr üben und so haben wir 4 mal mehr Chancen diese zu verbessern
  • unser Fokus 4 mal besser ist und wir so unsere Mühe 4 mal weniger verschwenden
  • wir 4 mal intelligenter arbeiten!

 

 

Posted in Agile, Kanban, Scrum | Comments Off on Sinn der Messung Zykluszeiten

WIP Limit Panic Sheet – what to do when you feel tempted to break the work-in-progress (WIP) limit

When a software development team starts using a work-in-progress (WIP) limit, everyone is calm and relaxed … until they are not.

panic

When you start to panic and feel the need to break the WIP limit rule – STOP! Read this special panic sheet first.

I have no tasks allocated to me

  • Focus on the user stories in progress:
    • See if there are any tasks that have not been picked up
    • See if there are any which somebody else may have been intending to pick up but is still busy with another task
    • See if there are any tasks which are missing and need to be added
    • See if anyone needs help with a task

Basically, if there is ANYTHING AT ALL that you can do to help finish a user story which is in progress, this is the HIGHEST PRIORITY

I don’t think there is anything I can do to help finish a user story

  • See if you can pair with someone. This might help to finish the user story, but even if it doesn’t, it will help with knowledge sharing.

I don’t think that I can usefully pair with anyone

  • See if you can improve some of the unit tests on a user story

The unit tests are fine

  • See if you can tackle some tech debt

I don’t think that I can tackle any tech debt

  • See if you can improve your knowledge of the codebase in order to be able to help with tech debt

My skill set is not around developing code, I’m a tester

  • See if you can improve or review any test scripts
  • See if you can learn anything about automation

None of the above suggestions will help

  • See if there is any other task which can be done to help either the team or your own knowledge

I’m the Product Owner – why doesn’t this person with nothing to do start a new user story?

  • Starting a new user story sooner does not mean finishing a new user story sooner. The completion of each user story is accomplished with the involvement of more than “this person doing nothing”. If there are already stories which are not finished yet, starting a new one will create more overhead for the team and potentially slow down the completion of those stories. It’s like throwing the team another ball to juggle. Have faith! Watch the baton and not the runner!

keep-calm-and-be-agile

Posted in Agile, Kanban, Scrum | Comments Off on WIP Limit Panic Sheet – what to do when you feel tempted to break the work-in-progress (WIP) limit

Beware of Scrumnesia – more transparency can make things seem worse than before!

I think this post is more about personal catharsis than anything else, but hopefully there is something useful here.

scrumnesia

I recently introduced a work-in-progress (WIP) limit with a Scrum team and was delighted that the average cycle time on user stories was its lowest ever for the team and several times lower than the overall average.

The team delivered everything that was planned for the sprint as well as tackling a significant technical debt and successfully increasing unit test coverage by a target percentage.

When it came to the retrospective, I expected nothing other than glowing pride in the team’s achievements.

But I was wrong!

There were several criticisms:

  • comparing the cycle times in this sprint to previous sprints is like comparing apples and oranges, because we broke down the stories into much smaller pieces
  • the functionality delivered was small and breaking a feature into smaller user stories means the whole feature takes longer to do
  • the WIP limit was too low because there was “idle time”

Wow! Quite a lot of criticism! Not all feedback was negative. The team also found some benefits to what we had done, but the Product Owner was the least happy.

Let’s look at these objections:

Comparing the cycle times in this sprint to previous sprints is like comparing apples and oranges, because we broke down the stories into much smaller pieces:
There are some mistaken assumptions in this statement. I have found it quite common for people to assume that Agile is all about “working faster”. This is a dangerous assumption, because it is simplistic. Honestly speaking, we should not expect developers to code significantly any faster than they already do. Coding takes time and thought, that is a fact.
No, what I expect teams to do is to work smarter, so that the considerable effort put in yields more in return. By celebrating cycle times several times lower than before, we are not claiming that the developers are suddenly typing four times faster! What we are saying is that the team has successfully delivered a slice of complete, good quality code which is useful to the customer and we can be confident that everything needed was done and we don’t need to go back to it to finish it off. We can also be confident that all of the team’s effort was focused on this user story and was not wasted on work which was not useful.

The functionality delivered was small and breaking a feature into smaller user stories means the whole feature takes longer to do:
It is interesting to think about the underlying assumptions here. Firstly all the stories which were planned were delivered within the sprint. In the sprint planning, we estimated each story just as usual and used our typical velocity to decide how many stories to bring into the sprint. What did happen in the sprint planning was that large stories were broken down and not all of the large stories made the cut, because there was too much. I think this was a case of the Product Owner wanting to put big stories in and not getting them in, whereas in the past, the big stories would have been brought in and then run over two or more sprints. This is where Scrumnesia kicks in. Once a big story is completed, it is sometimes forgotten that nothing was delivered in the previous two sprints! So, by breaking things down and making the size of the work more transparent, the output appeared worse! But I believe this was an illusion.

The WIP limit was too low because there was “idle time”:
I accept that the WIP limit may need to be adjusted up or down to get the right throughput, but I would question the assumption that “idle time” is a bad thing. I think that keeping a sustainable pace is important, and to do this, developers need time to gather their thoughts, they need head space for creative thinking, they need time to review code, to do a little tech debt, to help each other out and to learn. Working relentlessly on user stories is not sustainable in my view. It makes for disgruntled, burnt out developers whose ability to deliver quality will suffer.

What seems to cause alarm is making explicit what is needed anyway. Quicker cycle times are achieved by working on smaller pieces of work that get done well. Perhaps customers are surprised about how much work is involved in each small piece. Big stories don’t get completed in the time Product Owners would wish for, but telling that up front and giving them a reality check can upset them. Developers will take time out to avoid burn out anyway, or they might call in sick or spend an afternoon staring at the screen not doing much. This is natural. But admitting it seems more difficult.

Posted in Agile, Kanban, Scrum | Comments Off on Beware of Scrumnesia – more transparency can make things seem worse than before!

Cheat Sheet for Backlog Refinement

This post is from leadingagile.com by Derek Huether.

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

  • (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
  • (Optional) representative(s) from the Management Team – clarify the high level priorities
  • (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
  • (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items.  It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

Click here to see the full post.

Posted in Agile | Comments Off on Cheat Sheet for Backlog Refinement

Gamifying Scrum – it’s not enough just to stick a tatty burndown chart on the wall

As I am currently carrying out an Agile Coach role in Germany, I have been trying to discipline myself to spending regular time improving my German. Being a language enthusiast anyway, I have plenty of books and audio to learn German, however, I found myself not really applying myself to the task as well as I might.

But just as I was starting to worry that I was getting too old to learn languages, a friend of mine enthusiastically pointed me in the direction of duolingo.com – a free website for learning English, French, Italian, Portuguese, Spanish and … German!
My friend’s enthusiasm prompted me to take a look right away and I quickly found myself getting right into it. At last I was studying German with focus and regularity!

The reason for this dramatic turnaround? I have no doubt at all that it is completely due to the fact that duolingo.com uses a “gamified” format – there are levels, points, rewards, success, failure, progress tracking and regular feedback on progress in short cycles.
I did not stop there, I tested myself on Italian, Spanish, French and Portuguese to get some objective sense of how my competency in these languages compared. Sure enough the levels corresponded closely to what I expected.

Suddenly my mind has been taken over by the concept of gamification. Not a new concept. As a concept, it has been around forever. And even the coined terminology has been around since around 2002, I understand. And its use in business process and software applications has also been popular since around 2010. But importantly for me, it has only hit home now with this dramatic turnaround in my German language study.

So anyway, naturally, my attention turned to the gamification of the software development life cycle. I searched for “Agile Gamification” and plenty of results came back. I was excited that there are people out there already thinking about this, but also slightly annoyed that I was coming late to the party!

That is not strictly true. Scrum in any case already has many elements of gamification, for example:

  • for progress tracking we have burndown and burnup charts and the sprint provides milestones in short cycles
  • we use story points and velocity to measure effort
  • we have unit testing and build testing which can be green or red to indicate success or failure
  • we measure the health of the codebase using tools such as Sonar
  • there are rules to Scrum which provide the boundaries within which the “game” of Scrum is played

So, in a sense, you could say that Scrum is already very gamified and perhaps this is where the success of Scrum lies.

However, if your experiences are anything like mine, you will have seen Scrum teams operating in a way which does not have the fun feeling of a game at all. Instead, many is the time where I have seen Scrum turn into a turgid, depressing and apparently meaningless hamster-wheel of disengaged activity!

I have come to the conclusion that gamifying Scrum means bringing all these potentially game-like aspects of Scrum to life. We need to inject energy into the activities by embracing them and celebrating them. These potentially game-like aspects only become really game-like if we make them so: they have to be prominent, team goals need to be talked about, the progress tracking pointed out regularly. We need to make sure that we place importance on the game elements to show that they are significant. The presentation of this data needs to be attractive, appealing and varied to avoid it becoming like drudgery.

Colourful e-mails can be sent around to highlight successes or to alert about possible failures. And, like any game, the rules need to be taken seriously by the participants!
Online reward systems may be something worth looking at – I notice that there is a software called “RedCritter Tracker” which claims to be “the first and only gamified project management software”. But I would not let the absence of such a tool prevent you from adopting a gamified mindset to Scrum. Let the game begin!

Game
Work
Tasks
repetitive, but fun repetitive, and boring
Feedback
constantly once a year
Goals
clear contradictory, vague
Path to Mastery
clear unclear
Rules
clear, transparent unclear, in-transparent
Information
right amount at the right time too much and not enough
Failure
expected, encouraged, spectacular, brag about it forbidden, punished, better not talk about it
Status of Users
transparent, timely hidden
Promotion
meritocracy kiss-up-o-cracy
Collaboration
yes yes
Speed/Risk
high low
Autonomy
high mid to low
Narrative
yes only if you are lucky
Obstacles
on purpose accidental

Table taken from here.

Posted in Agile, Gamification, Scrum | Comments Off on Gamifying Scrum – it’s not enough just to stick a tatty burndown chart on the wall

Waking the team from “the They” mode

One of the realities of working with a development team to help them change and adopt an Agile mindset is the fact that, as human beings, it is very natural for us to slip into a routine, to go along with the status quo, keep quiet about long-standing issues and generally blend in. It is all very well, for example, agreeing to be self-organising, promising to focus on one story at a time, sticking to a particular engineering practice, such as TDD or code reviewing and so on, but adopting new habits requires concerted focus and special effort, which implies that it is very difficult to maintain.

Personally, as a former student at various times of existential philosophy and psychology, this makes me think about Sartre, who spoke about the courage required to take personal responsibility, while Heidegger described “the They”* as our most natural state of being.  By “the They”, Heidegger was referring to the same kind of phenomenon that I mentioned above: blending in, going with the flow, doing what “they” do. This is a state of being in which we do not take ownership. We do things because “that is just what one does”, so we do what “they” do, “they” being a kind of general accepted consensus. Heidegger felt that we were in this state for most of the time.

This tells me two things in relation to changing habits, activities and culture within a team: firstly, we should not get too upset when people slip into “the They” mode – this is absolutely to be expected. Secondly, as a coach, I need to find ways to encourage the team to come out of “the They” mode into what Heidegger called “my owned self”** – a state of being where we take ownership of our own actions.

There are lots of things a coach can do to stir a team from the “psychological slumber” of “the They”. Here are just a few I have tried recently:

– asking probing questions in forums such as the retrospective (for example: “What can we make of the fact that we did not deliver all of the user stories that we committed to delivering?”)
– calling things out in the daily stand-up or in other meetings (“I notice that there are a lot of user stories in play”)
– setting targets for unit test coverage
– using statistics to show patterns in work flow

My latest idea was to give the team a questionnaire. The intention was to encourage the team to reflect on their everyday habits with the hope that this might invite and inspire them to try something new. I handed out the questionnaire in advance of the retrospective and asked the team to bring the completed questionnaire into the retrospective and to discuss their responses in small groups of two or three. I told them that I did not want to see the answers myself, but invited them to each consider taking one personal action in light of the discussion of the questionnaire. These actions were put on the board without names, so it was purely left to the individual concerned to take the action or not, but at the same time gave others the opportunity to see what actions were taken by others. I think the private, “self-regulatory” format was an important part of this to ensure that the team did not feel that this was something for me.

For the sake of completeness, here is the multiple choice questionnaire I put together. It undoubtedly reflected what I consider to be positive behaviours for the team, so it was not totally neutral. Perhaps there will be different opinions about this. I am sure that someone else could come up with many other possibilities and/or improve on this:

I learnt new things in this sprint

  •     I learnt a lot
  •     I learnt a few things or one or two really useful things
  •     I didn’t really learn anything significant

I worked out of my comfort zone during this sprint

  •     I did this quite a lot
  •     I did this some of the time
  •     I did not do this much

By working with other team members, I learnt something new and/or enabled someone else to learn something new.

  •     I did this a lot
  •     I did this some of the time
  •     I didn’t really do this

In this sprint, I focused on doing my own tasks without worrying too much about what everyone else was doing.

  •     I did this most  of the time
  •     I did this some of the time
  •     I worked mainly in collaboration with others

In the last sprint planning session, I understood the user stories well enough to be confident that I could finish work more or less according to estimates.

  •     I understood most user stories well enough
  •     I understood some user stories well enough
  •     I did not really understand the stories well enough and things took much longer than expected

I get irritated and/or bored when a user story goes on and on and on and on….

  •     Yes, I usually get irritated and/or bored by this
  •     Sometimes it bothers me
  •     I don’t really care to be honest

My intention with some of these questions was to prompt team members to hold up a mirror to themselves. If for example, I realise that I learnt nothing in the last sprint, I might be prompted to think: “what am I getting out of this if I am not learning?” or “well, it would be nice if I could learn something next sprint” or “I want to make sure that I learn something every sprint!”

Or if I acknowledge that I did not come out of my comfort zone, this might prompt me to consider that this could be a cause of boredom, for example.

Other questions were designed to encourage people to think about the purpose and usefulness of particular activities in the sprint or simply to prompt people to be curious about how they acted within the sprint.

In summary, all the questions were meant to stir people, to wake them from “the They”.

 

 

* “the They” is also known as “the One”, as in “what one does” which is a closer literal translation of Heidegger’s original terminology in German: das Man. But “the One” also makes me think of “the chosen one” as in The Matrix, etc.

** “my owned self” is also known as “my authentic self” – I prefer the former translation because “authentic” in modern English seems to imply too strongly that it is somehow a “better” state of being. However, Heidegger intended no value judgement in his description. The original terminology in German is: eigentlich

For more on Heideggerian terminology, see: http://en.wikipedia.org/wiki/Heideggerian_terminology

Posted in Agile, Scrum | Comments Off on Waking the team from “the They” mode

The Art of Embracing Change

This post is from agilecoach.typepad.com by Rachel Davies.

I enjoyed giving a keynote speech at GOTO Berlin about “The Art of Embracing Change”. The title of my talk was inspired by the subtitle of Kent Beck’s “Extreme Programming Explained” and of course coaching is all about change. Keynotes are supposed to be opinionated and provide food for thought so I gave it my best shot.

At the heart of software development is an important truth “all things must change”. Software is an amazing invisible material made of thought that can be changed any time – its softness is a defining characteristic. The available technology (frameworks/languages/libraries) that we can use to solve business problems evolves and business needs also change as the market evolves. Change is something a software developer is likely to grapple with throughout their career. Our instinct is to cope by fighting change, we owe it to ourselves to get better at anticipating change and handling it.

Click here to see the full post.

Posted in Agile, Transformation | Comments Off on The Art of Embracing Change