Definition of DONE of an Agile Transition.
Any questions?
aot 2010Monthly :
Start doing sprint reviews, not demos
There’s a misunderstanding I’ve noticed in quite a few Scrum projects. Teams use Scrum and at the end of their sprint they do what they call a “sprint demo”. It works out like this:
- They demonstrate their increment of the product to the product owner
- Product owner seats passively
- Product owner accepts or rejects the increment
- No modification is done to the product backlog
- After a while the product owner is unhappy with the current state of the product and the progress being made
There is nothing like a sprint demo in Scrum. But there is a sprint review.
Scrum is empirical, meaning that there are inspect and adapt points along the way. The sprint review is the inspect and adapt point where the product increment, the most current product backlog and the current conditions are for inspection. The adaptation is the modified product backlog.
During the Sprint Review, the Scrum Team and the stakeholders collaborate about what was just done during the sprint and what are the things that could be done during the next sprints. The presentation of the product increment is not the goal. It is used to understand what should be the next sprint goal. The sprint review provides input to the next sprint planning meetings. One of the possible consequences of this evaluation is the decision to not proceed further with the development of the product. Another possible consequence is the decision to release the existing product.
Consider your next sprint review. If you get out of the meeting without a modification to your product backlog and an insight to your next sprint goal, it’s probably because you’re not inspecting and adapting. You might be suffering from the “sprint demo” syndrome.
I don’t believe in self-organized teams…
Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic.
“Can you share with me your reasoning?”, I asked him intrigued.
The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction.
Indeed, I thought to myself. Who said people and teams shouldn’t be given clear objectives. On the contrary, in my opinion, clear goals are necessary for teams to organize otherwise you end up with a bunch of people who will try to find a reason, a purpose why they are all together – and their self-created goal may very well be different from what you had in mind in the first place.
Where I have a problem is that people associate self-organized teams with “abandoned teams” meaning you simply let the team figure it out – whatever “it” is.
In order to reach the level of autonomy they need to demonstrate extra-ordinary performance, teams need to reach the right level of maturity. Consequently, the manager’s leadership style is critical to achieve that objective. Within Pyxis, we often rely on the combination of the situational leadership and the group development stages to determine the proper level of involvement from the manager.
(Tuckman’s stages of group development, Situational leadership theory)
One of the way to achieve the right level of maturity is for agile managers to determine WHAT must be accomplished and let the team determine HOW it will be done – I already shared my opinion on this topic. Granted, things are more complex that I make them sound in this post but self-organization is indeed possible when the right environment is created for the team – including clear objectives – and it is then given the latitude to operate and determine how best to achieve the given goal.
If only managers would be willing to let go some of their (need to) control and trust the teams, a higher level of performance can be attained.
As you may have guessed, the candidate wasn’t called back for a second interview…
You might be interested in these related posts:
Ayez le Scrum Robuste!
Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement. Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de livraison de qualité “production” au fil des itérations. Martin Fowler a nommé ce phénomène le Scrum Flasque.
Le cours “Professional Scrum Developer” offert à Pyxis vise à contrer ce problème en replaçant l’emphase sur les bonnes pratiques de développement essentielles à l’atteinte des objectifs de Scrum.
Le développement piloté par les tests (TDD)
Nous avons pu mettre en pratique le TDD dans toutes les facettes de l’application, aussi bien pour le développement en tests unitaires qu’en tests clients (bout en bout). Ceci nous a permis de nous rendre compte qu’il est possible de couvrir la quasi totalité du code par des tests automatisés. En conséquence, le code obtenu est robuste, explicite et diminue le stress du développeur qui sait que ses changements seront plus faciles à implémenter dans le futur.
Choix technologiques
Certains choix technologiques peuvent rendre difficile, voir impossible l’application des bonnes pratiques et donc l’objectif de Scrum Robuste: la livraison itérative de logiciel de qualité. Il est par conséquent essentiel de choisir un ensemble d’outils (langages, cadres d’applications, environnements de développement) qui supporte convenablement ces pratiques. Un exemple parmi tant d’autres, le cas d’utilisation étudié durant la formation utilisait une librairie de rendu visuel légère et testable. Ceci nous a permis de facilement tester les vues de manières unitaires, ce qui est malheureusement rarement possible…
Elimination des mauvaises odeurs de code
Les mauvaises odeurs de code (aka Code Smells), comme par exemple les duplications ou les classes géantes, sont des causes fréquentes de difficulté à maintenir une base de code et d’une réduction de la vélocité des équipes. Le cours nous a permis dans le cadre de la pratique du TDD, de veiller à enrayer en continu, par le “refactoring”, ces mauvaises odeurs.
En conclusion, il faut garder à l’esprit que Scrum ne suffit pas en soit à livrer du logiciel de qualité. Scrum doit nécessairement être entouré de bonnes pratiques de développement, telles que celles enseignées durant la formation pour éviter de sombrer dans la flaccidité.
Allez-y, soyez robustes du Scrum! 
Marc-André Thibodeau et Gaël Luisier
Are We Done, Really Done or Really Really Done ?
This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned.
One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D).
For most of us, even with our extensive Scrum background, this was actually harder than we had originally expected. The training course consisted of 4 sprints spread over a 4 day period. At the end of each sprint, we had to demonstrate our accomplishments to the Product Owner.
At the end of the fourth sprint, we had to put our software into production.
Like most teams, we started out with a D.O.D that was too ambitious and wasn’t clear enough. For example :
- We had planned for 100% test coverage for all of our tests, yet it was impossible to demonstrate since we were unable to calculate code coverage for view tests. Even worse, there was simply no available tools to calculate our test coverage for these.
- We also had ambiguous elements, like following the code standard, without stating which one.
After achieving first sprint, we did what we thought were the proper modicifications to our done definition. As you can guess, we failed our second sprint. Our done definition was being seriously violated. We committed to too many tasks and did not take the time to truly understand all the work involved in achieving our done definition. We adjusted for the following sprints. Inspect and adapt as always.
However, when came the time to release the product, we realized that our done definition was seriously lacking. We had no confidence in being able to ship our product to the customer. The Product Owner was disappointed in learning this. We then had to modify our done definition to finally be able to deliver. Unfortunately, we had skipped some important steps in the previous sprints which accumulated up until the last day.
Here are few key points that were missing :
- Exploratory testing
- User Experience testing
- Proper production deployment procedure
This really helped us see how important it is to have a true definition of done and to follow it through sprint after aprint. After all, we had accumulated debts after only 4 days of sprinting. Imagine if we had been sprinting for weeks !
-Nicolas Henin and Nicholas Lemay
Rediscovering ERB (without Rails)
Since I discovered Haml for my HTML templates in Rails, I stopped using ERB. Haml is more intuitive and readable to me.
I am rediscovering ERB though for something else completely – Java code generation.
There is a lot of boilerplate code in most Java projects. A good IDE can help you alleviate some of it but most (if not all) applications will have additional boilerplate very specific to your application. Using ERB, you can easily create cut down on mindless typing.
For example, let’s suppose you are writing many Java listeners. Just create a script that will do it for you. I’ll make an exemple with a ContactListener class that is notified when a user is added, removed or blacklisted from your contact list.
require 'rubygems' require 'erb' # setup - could be initialized from script arguments classname = "Contact" listener_methods = ["added", "removed", "blackListed"] # create file based on 'listener.java.erb' content = File.read('listener.java.erb') template = ERB.new(content) File.open("#{classname}Listener.java", 'w') { |f| f.puts(template.result) }
If I run this using listener.java.erb:
public interface <%= classname %>Listener {
<% listener_methods.each do |method| %>
void <%= method %>(<%= classname %>Event event);
<% end %>
}
Then I generate this file:
public interface ContactListener { void added(ContactEvent event); void removed(ContactEvent event); void blackListed(ContactEvent event); }
That was easy – and it’s not that useful I admit. I’m sure you can create your own listeners just as fast in your own IDE. Probably even faster.
However here comes the fun part – the same script can be used to create lots of other classes:
- The ContactAdapter class
- The ContactEvent class
- The ContactController
- The Contact model
- The ContactRepository (maybe even with a few methods to add/remove/retrieve a contact by id)
- The ContactView through which users will be able to trigger ContactEvents (maybe with a simple UI – even buttons to trigger each events on the ContactHandler)
- Registration of the ContactHandler and the ContactView by your favorite IOC framework
- Registration of the ContactView so it is accessible from your application’s menu
- Test classes for all of the above (including failing test cases that you’re going to have to write)
And probably other bits here and there to glue everything together.
Your mileage may vary, but code generation might be a great way to make your path shorter.
Can your IDE do that?
A guide on getting value out of your Agile2010 experience
Agile2010 has come and gone. Hopefully, so did the rain. But what exactly have you gotten out of it ?
- As an attendee, you might have attended a few sessions which did not meet your expectations, but also hopefully a couple of eye opening ones.
- As a presenter, you might have conquered your crowd or failed miserably to spark their interest.
- As a sponsor, you might have had the chance to meet a few potential customers or have realized that no one is interested in your offering.
Where do you go from here ? Having attended a couple of these conferences, here are a few tips we have gathered throughout the years.
Attendees
- Don’t worry too much about the sessions you found less inspiring. Focus on what interested you in the first place and try to get more information on the subject. Your favorite search engine is your friend here.
- If you met a great presenter, feel free to try and contact them. You’d be surprised to see a lot of them have a blog and/or use Twitter. Many of them will answer some of your questions. Keep the presenter’s name in store to help you select the sessions you want to take part of at Agile 2011.
- You’ve certainly missed a couple of interesting presentations. You cannot be everywhere at once. You can always go back through the schedule and see what you missed. Once again, a lot of presenters will put their slides on the net. Plus you might be able to exchange with them online.
- Remember, attending is often just a way to spark interest. You’re the one who has to do the research afterwards.
Presenters
- Many many thanks for sharing your experience with the community ! You are the essence of this conference, make sure you start collecting ideas for next year!
- Read the feedback forms ! Got aspects you need to improve ? Ask around for help. Getting better is always easier when done in teams.
- Have a blog ? Ask people for feedback. Publish you slides. The more you open up for feedback, the better you will become.
- First time presenting at a conference ? Present again. Soon. The more you do it, the more feedback you will get and the more you will develop a natural “feel” for crowds and how to handle them.
Sponsors
- You’ve seen the interest in your offering. Good. That was the easy part. Now is the time to make something so good that people will enjoy it year after year after year. When they come back for more, then you know you’ve got something great in your hands.
- You’ve seen that people do not like your offering ? Excellent ! You’ve just saved tons of money. How much more would you have spent if you had not met with your real customers ? You are now armed with a lot of valuable information. Use it !
Between a rock and a hard place – The managers in an agile transition
I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.
In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.
So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…
- Me: “Hey, Steven. You look tired. How are you doing?”
- Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
- Me: “How so?” [I asked anticipating what he would tell me next]
- Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
- Me: “You seemed so excited about the transition when we started. What changed?”
- Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
- Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
- Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”
Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?
We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.
For those who haven’t yet have felt the pressure, here are some examples of what to expect:
- You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
- You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
- You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
- You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?
Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…
You might be interested in these related posts:
Where is the turtle heading?
Now that the vacations are over and that the 2010 Agile conference has come and gone, Team Urban Turtle is back to work, cooking up another promising release 3.4.
With the release of the Scrum template from Microsoft came a Removed state, making it necessary to propose a recycle bin feature to our users. The next version of Urban Turtle will therefore include a recycle bin icon at the top of the iterations and areas panel. Users will be able to drag and drop items onto it to set the state of selected items to a configured deleted state. It will also be possible to view deleted work items by clicking on the icon.
The team is also working on a select / unselect all option to flag or unflag all iterations and areas as favorites in one click.
We have several more interesting features in our backlog, some of them coming from customers who voiced their opinions and proposed suggestions on our community-powered support site. Thank you all for your support and keep those suggestions coming!
} Dom
An interesting way to fund projects
Incubators are looking for ways to differentiate themselves. The newly launched AngelPad (an incubator created by 7 ex-googlers), for instance, bets on recreating a google-like atmosphere to foster innovation.
A recent post from Mark Shuttleworth seems to show that some foundations also have interesting ideas when it comes to financing projects :
“The model of the Foundation is unusual: we identify interesting change agents, like Mark, who are articulating powerful ideas that seem like the offer a hint of the future, and we fund them to work on those for a year. We also offer them an investment multiplier: if they put their personal money into a project, we multiply that by 10x or more, up to a maximum amount. In short, find good people, back them when they put skin in the game.”
Now, I am wondering about something : could incubators be a model for managing companies ?
- What would happen if you created a company that was merely a kind of aggregate of smaller companies sharing a common vision but running mostly independantly ?
- Could the Politics of Switzerland be an inspiration for creating such an ecosystem ?
- How much federal government do you need to have inside a company to have the perfect balance between “feeling like a single company” and “feeling empowered enough to do things without any bureaucracy” ? (do-ers hate bureaucracy, so if you want doers in your company, you’d better find a way to systematically fight it if you want to keep these people)
- Is is possible for people to feel part of their community without neglecting the rest of the ecosystem, the same way Texas inhabitants feel both texan and american ? (Have you noticed that people have both the texan flag and the american one in their garden over there ?)