May not be what people hear… Therefore it’s really important to listen to people, asking probing questions to ensure the intent of your message got across. I’ve seen many people (including myself) fall into the trap of focusing on delivering the method, that we never test to see if it made it across.
Page 42 of 53
In considering a leaner approach to software development, many people in the agile community are starting to turn towards an iteration-less approach. Wayne Allen talks of trialling No More Iterations, while Amit Rathore talks about an iteration-less agile process. Heck, I’ve even given it a go with a couple of my projects. On the other hand, there’s a whole movement in Italy devoted to the Pomodoro (Tomato) Technique that focuses on time-boxed activities.
So who’s correct?
The short answer: They both are.
Photo of a “time box” from Great Beyond’s Flickr stream under the Creative Commons Licence
The long answer: When you compare people not working in an iterative fashion (i.e. one phase of analysis, one phase of development, etc), to those agilists now turning away from iterations, there’s a noticeable difference, and is what I will call, discipline.
Those arbitrary time boxed units that we call an “iteration” creates cadence for teams. Cadence in turn creates rhythm, where teams can focus better on developing the healthy habits associated with agile software development. Much like the way that beginning martial artists repeat katas, it helps the Novice, Advanced Beginner and the Competent (Dreyfus Model) understand each practice individually and develop the discipline to make them effective. They don’t need to worry about which practice combines best with other practices, and yet, still see some benefit. It helps the team synchronise, predict and potentially even enforce when activities happen, giving people the stability they need when they are learning. It forces people to make important decisions that, without the associated discipline, end up deferred.
In absence of iterations, you need a guide to achieve a similar effect to encourage people to use the practices in an appropriate order. I argue that those people who are Proficient or Expert (Dreyfus Model) don’t need the iterations because they understand when to use what practice and the value it brings. They move towards what looks like an “iteration-less” approach because they are instinctively doing things iteratively without the arbitrary time box. They have enough discipline to ensure all the activities happen at the right time without causing disruption. Unfortunately, in my experience, many never make this jump to being Proficient or Expert.
What to do about it?
Iterations are useful, with that usefulness limited to a certain context. The learning level of the people involved heavily influences this. Respect the needs of the people you work with, and understand that jumping into “no iterations” requires a level of discipline you won’t achieve without people reaching these later levels of mastery.
One of my most memorable conversations during training went something like this…
Student: Aren’t these just best practices? I don’t see how this is agile estimation. How is this agile?
Me: Hmmm. I guess they are best practices. I see many agile teams frequently apply all these techniques when they do some estimation. Let me ask you about your current project. Do you get people who will do the work to give you estimates?
Student: No. Either we have a group of architects to estimate the work, or I estimate the effort for the team.
Me: Do you try to make make sure more than two people estimate?
Student: No. One person should be good enough to estimate.
Me: Do you try to understand or uncover the assumptions that person is making during estimation?
Student: Sure. We ask them to write their assumptions down.
Me: Do you use relative estimation?
Student: No.
Me: So you’re telling me that even though these are best practices, you’re not necessarily doing any of them?
Student: Yes. But I don’t see how this is agile.
When people get fixated with disagreeing about something, they stop listening and stop learning. Drawing them out of this corner can be a really difficult task. In this particular case, the student wanted clear evidence that agile was something else and wasn’t prepared to hear about estimation best practices being normal best practices when working in a most agile methodologies.
An issue I see in many IT parts of an organisation is that niceness trumps honesty most of the time. I entirely support the whole No A*holes Rule, so being nice is a good thing to focus on yet it shouldn’t be at the cost of telling the truth.
Photo from Striatic’s Flickr stream under the Creative Commons Licence
Here’s what to avoid. Do not say yes to requests you know you cannot make. Do not say yes to requests you don’t know if you can or cannot make (qualify it, or suggest an alternative that will allow you to eventually answer yes). Do not say yes to simply what they say – spend some time to find out what they really want.
Telling people truth around what you and cannot deliver is much nicer than simply saying yes because it doesn’t lead to disappointment and it leads to conversations about what you can deliver that works.
In one of the conversations I had at the XP2008, I remember talking around the social effects of introducing agile. We shared a number of stories and some things that we’d either seen personally or heard from someone else. One of the patterns we observed we decided to call the Agile Ejection Effect.
Photo from Bayat’s Flickrstream under the Creative Commons Licence.
Definition
The change that results in a certain number of people leaving a company through the introduction of agile methods. This change is typically triggered by two different causes, one where people leave because the system changes, and the other where people leave because the system does not change.
Those individuals that leave because the system changes towards agility find that their conventional ways of working and reporting have less impact, or are no longer appreciated. They may no longer understand how their role fits into this new system, and feel more comfortable leaving to find the older and more rigid environments they are more comfortable with.
Those individuals that leave because the system does not change probably had some success with one particular project, only to find frustration and resistance in the next project by not being able to work in the same manner. Larger issues such as governance and broader organisational concerns create resistance to working in these new methods and the individual decides that leaving to find an environment and culture is a better way to spend their energy.
What is it?
The European equivalent of the Agile20xx conferences, this year held at the University of Limerick Ireland. With less than 200 delegates (including presenters, paper writers, attendees, and organising committee) it trades off the wide spread of topics you get with 1000+ people for the corridor conversations and many opportunities for networking.
General Observations
With participation significantly down from the previous year, plenty of people talked whether or not it was losing its appeal. For the organising committee, they thought they should rebrand it (to something broader than XP) as they think that turns a lot of people away without realising the topics are much broader. Other corridor conversations uncovered its focus on the more academic world was starting to turn practitioners and industry-experienced people away, something I know some people reacted to based on last year’s experience.
Trends in the agile community
Scandanavia continues to adopt and seemingly lead most European adoption of agile, with representatives from Finland and Norway consulting and leading change in organisations. There didn’t seem to be many representatives from a single country, with the more noticeable trend focused around companies (like Siemen’s Nokia) sending representatives to learn more about agile.
Compared to many other years, it doesn’t seem like the European agile community is leading much innovation in this space. A number of sessions focused more on the softer side of agile including agile coaching, organisational change, and most of the keynotes more focused on case studies more than cutting edge ideas (with the exception of Dave Snowden).
Memorable Keynote on Complexity and Agile
Dave Snowden is an opinionated and thought provoking speaker with both feet in the industry and academic worlds. He argues that without a sound scientific model, you will never get the most benefit out of things and with that, talked about the relevance of complex systems (opposed to ordered or chaotic ones) to agile. I can’t do his talk justice and his company’s website has many more resources about this, including a podcast of his keynote (see Resources link).
To put in briefly, most scientific models base their assumptions on the idea of order or chaos. Order allows you to plan, chaos allows you to predict based on statistical analysis. He argues that most models are actually complex – you cannot plan or predict based on statistics because there is not true cause and effect between items. In a complex system, the agents in the system change in response to other things going on in the system. This is the case where repeating the same thing and expecting a different outcome (in a different context) would be highly likely.
He talks about ways of managing complex and complicated systems instead of what most people focus on (simple and chaotic) using the Cynefin framework. For complex systems, it suggests managing best using a Probe-Sense-Respond. In complicated systems, it’s Sense-Analyse-Respond. How this works in the real world, is about understanding what system you might be dealing with and use the appropriate system. If you’re working in a complex system, it’s worth probing (spiking), sensing (look for positive and negative behaviours) and responding (by encouraging factors that lead to positive behaviours and discouraging factors that lead to negative behaviours).
In many ways, I feel this is one of the ways that we commonly work.
- Probing = Time boxing work with some monitoring
- Sensing = Retrospecting and reflecting about things that went well, less well
- Responding = Adapting the process, or environment to suit
Agile Coaching becoming more important
The Agile Coach role (perhaps what might be mapped best to Iteration Manager for us) is starting to become a recognised role with the need to investigate what it means and help others into it. Liz Sedley and Rachel Davies ran two sessions focused on what it means to be an agile coach and what things the role focuses on.
Feedback on my workshops
After meeting a number of delegates from previous years, I was pleasantly surprised to see that some of them are still successfully using the material from my Test Driving Your S-Wing session I ran two years prior.
I also enjoyed running this year’s workshop called Biohazard: Engineering the Change Virus, focused on understanding change at an individual level rather than at an organisational level. We had plenty of great discussion and lots of story-telling that at least made me feel people understood the material and have a better chance of introducing beneficial change when they go back to their day job.
We think that agile software development is currently the best way of developing software, yet it hasn’t been adopted by all software companies in the world. Why? The answer – it’s really hard for people to fully embrace change.
Teams and organisation get stuck in their ways, and even cultures of continuous improvement and openness to change slowly build up a resistance until change no longer occurs.
This two hour workshop aims to raise your awareness of agents against change, and equip you with practical skills and techniques that will help you bolster the strength of the change virus. We’ll look at ways of taking it to a point where it’s so contagious that it has a life of its own.
Specifically we will:
- Investigate sources of resistance to agile practices
- Look at a number of patterns for helping others to embrace change
- Examine influence and different styles of influencing
- Share a number of case studies where these were applied to improve agile adoption and inspire a culture of continuous change.
- Recognise where change patterns can fail and common pitfalls
Resources:
I’m a big believer in letting people try things out. Unfortunately, most training programs don’t let people do this enough. In fact, most of the time, training is seen as some way of “fixing problems” or a “all-in-one solution”. I can tell you a simple reason why training fails… people don’t have support to actually use the things they are trained on. They don’t get the essential feedback loop in their real environment and they quickly forget what they learned.
It’s all fantastic when you have an opportunity in class to try what you learned out. What really matters if whether or not you have long term lasting support in your environment to apply it to what you do. Unfortunately most training programs fail to address that, or the trainers don’t feel like it’s something they can influence.
Training lasts a day. True learning lasts a lifetime. If you send people on training, make sure they have a safe environment to apply it as well. Don’t view training as a silver bullet. Use it as a tactical solution as part of a larger strategic initiative.
The Agile Coach, from A-Z released on InfoQ today.
Recent Comments