We will be hosting a short series of talks about agile software development this autumn. I’m first up, and I will be talking about the bottleneck in software development, and how agile practices help.
If you speak Swedish and feel like getting free breakfast and a little inspiration – send us an email!
More information, all in Swedish can be found in this PDF.
Churning out story points is not enough. You have to build for tomorrow, not just for today.
Something I see again and again is teams breaking their backs trying to produce as much functionality as possible. The business have a great tool for measuring the productivity of the team (story points), and this leads everyone to try to perform well on that axis.
The result is bad code that doesn’t scale, is buggy, and hard to understand for everyone. Introducing new features is done by copy-pasting and changing a little. Changing features is hard to do in a consistent manner – you are always afraid you missed something somewhere.
I think that the background to this mess is how easy it is to measure story points, and how hard it is to measure code quality.
Code, to me, has three distinct values, and I don’t think I’m alone thinking this.
1. What the code does
If the code doesn’t do what it’s supposed to do, it’s of little value to the business. In this value, I also group stuff like performance, scalability and responsiveness. Badly performing code can be as bad as code that doesn’t perform at all – from the business’ perspective.
2. How easy it’s to extend and change
Adding new features, and changing underlying dependencies is what I think of here. How hard would it be to switch from our home grown cache to memcached? Is adding a new supplier as easy as creating a new class and changing a configuration file, or do you have to do major surgery and add new code in unrelated classes to make the change? Giving the business the option to change their mind is very valuable.
3. How easy it’s to understand
And, of course, you have to understand the code you work with. New developers shouldn’t need months and months of training in the code base to become productive. I put consistency of the code here. If you learn one part of the system, you should be able to quickly be productive in other parts of the code. I value the code base as a whole. I often see really clever developers running away from the rest of the team. What this leads to is difficulties for everyone else. No-one dares touch the brilliant developers code, because they don’t understand it.
When you work with code, you can’t constantly be adding to one value at the expense of the other values. Just adding new functionality, and not improving extensibility and readability is bad business. You are
putting up yourself for failure later on. At the same time, you shouldn’t make the code easier to understand by just removing functionality. You need to strike a balance that doesn’t hurt you in the long run.
That’s why I always want teams to have a tech lead. Someone should keep their eye on the non-functional values of the code base. It’s easy for everyone to be drawn into the race for story points in the current iteration. Instead, taking on a little bit less, and using that time to make the unit tests easy to read, or start refactoring that huge database class makes a lot of business sense. It’s difficult for the product owner to see this clearly, so team, with the help of the tech lead, have to make this a priority.
I code because I love to code. Solving problems, and seeing people using stuff I created gives me a huge kick. But still, some coding projects are fun, and some are horrible. What is the difference between the two?
A couple of years ago I worked in a project that technically wasn’t very exciting. We had a lot of legacy .NET code, and the database we were using was a Win16 thing that should have been shot dead a long time ago. We accessed with it through a couple of unstable 16-bit COM objects. To make matters worse, we used a third party chart and grid utilities that just wouldn’t cooperate with us. And still, every morning, I was eager to get to work. I really enjoyed working in the project, and I was sad about getting close to the end of it. Let’s call this project Alpha.
In another project I remember, the client basically gave us free reins. We could do things how we wanted, both technology and methodology wise. We picked all the fun stuff, like WPF, WCF and nHibernate. We had no legacy code at all. The team was an experienced group of developers. Everything looked perfect. And it was the worst project I’ve ever been on. I’ve never been so angry, sad and frustrated in my professional life. Every morning was dreadful – I didn’t want to go to work and I counted the hours until the end of the day. Let’s call this project Beta.
I’ve been racking my brain, trying to come up with what the difference was. Clearly, the technical challenges are not what defines a project as enjoyable or not. So what it is then? What made Alpha a fun project, and Beta a nightmare?
The biggest difference, in my opinion was that in the Alpha project, the client had a very strong feeling that this project was a do-or-die thing. Everyone cared immensely how things were progressing. It’s not hard at all to have a sense of urgency when the client cares so much about what you do.
In the Beta project, our boss and project manager was only doing this project part time. For him, it was a long shot, outside of the “real” business we were engaged in (consulting). The client had a similar situation – they were high-paid consultants themselves, and saw this project as an interesting side-kick, not core business. They didn’t have time to really be involved in the project.
I get my kicks from fulfilling someone’s needs. I want to feel that I’m making a difference. Either by changing peoples way of working, and improving their quality of life, or by making a great product that someone really cares about. One of the key things a good product owner brings to the team is this feeling that what the team is doing matters. Share your enthusiasm freely with the team – it will make them better!
What does it actually mean to be a project manager? What do you expect a tech lead to do? Does everyone in your organization agree with your definition?
A very common problem that we encounter with our clients is that roles and titles mean different things to different people. This is a troubling not only because it makes it difficult to understand each other, but also because people have disparate takes on what’s expected of them.
We have developed an exercise that helps expose the problem, and gets the team thinking about how they communicate. We call the exercise Roles and Responsibilities.
The exercise
Gather the part of the team that should be involved. Not everyone in the team needs to participate. It’s important to have the key persons there, but too many persons slow things down. 4-6 participants, plus a facilitator should be fine.
List the roles
Now list the roles that your current process uses, and put the roles on the whiteboard. It’s important to keep individuals and roles separate at this point. If you have a tech-lead role and a ScumMaster-role, and they happen to be one person in your team, you should still list two separate roles. Roles that often cause misunderstandings are: project manager, tech lead, architect, test lead, CTO, iteration manager, tracker, Scrum Master and product owner.
List the responsibilities
Next, have the team brainstorm what these roles need to do to fulfil their responsibilities. At this point, it’s just important that it’s something that is done by one of the roles on the whiteboard – which one is not important. What you list should be as hands-on as possible. Things like communicate the architecture, facilitate the retrospectives and send out weekly reports are good items. Listing things like innovate is not helpful. Write the items on stickies, and assemble them in one big group on the whiteboard.
First filtering
When the participants have run out of ideas, it’s time for the next step. You should now have the roles written up on the whiteboard, and one big pile of stickies with things to do by these roles. The facilitator picks one of the stickies, and asks the participants which role the activity goes with. If there is any discussion at all, move it to a “Discuss Later” pile. This first run through is just to get all stuff that everyone agrees on out of the way. After this step – take a minute and reflect on what’s left on the board. This is the root of a lot of the misunderstandings that the team has.
Talk talk talk
What’s left on the board now are the things that the participants don’t agree on. The participants now have to talk and discuss until they discover a way to communicate that is helpful for everyone. Make it clear to them there is no right and wrong – the point is to make explicit what people mean when they talk about the roles, and to make it unequivocal to everyone what’s expected of them.
We’ve used this exercise successfully with a number of clients. It’s by no means a cure-all, but it makes the problem a little more visible. Hopefully it will get the team working on creating a common language and being explicit about what they mean. Good luck!
We’re hosting conference in Malmö, Sweden in September. Heavily inspired by Agila Sverige, it’s a participant driven open space conference for agilistas in the Øresund region. I would love to meet you there!
Introducing change is always hard. That’s why I attacked changing organizations from the technical side – it’s where I feel secure. I’ve recently had the chance of introducing agile practices in a company from the top down.
The company has gone from having big problems delivering high quality software, to a highly focused team that outperforms it old self many times over. In this post, I’ll tell you what we’ve changed, and what they do that has helped them be successful in introducing agile thinking.
Difficult to take the leap
The company had been looking for a new and better way of working for some time, but felt that they lacked courage to do it on their own. Their lead developer/project manager had gone to a Certified Scrum Master course, but they didn’t know where to start implementing Scrum.
After some talk, we decided that we should do a three day diagnostic that we’ve used successfully with other clients. The idea is that we spend three days learning as much as we can about the company. We try to understand how things get done, and who decides what gets done. We take this information and present it back to the customer, and give advice on what the first steps might be to improve their current reality.
Intelligence gathering
We quickly found that their three biggest problems where:
1. Release management
2. Team communication
3. Long time to a working system
Their biggest problem was the release procedure. The first naive write of the code wasn’t hard – getting it reviewed and bug free was the challenge. This is roughly the life time of a ticket:
assign ticket -> code -> review -> test
There was no urgency to finish off tickets, so stuff piled up after the coding activity. Review and test was pushed of until the latest possible moment, which of course meant that fixing problems and misunderstandings was twice the effort.
The team used FogBugz to track, plan and assign work to each other. The lead developer and the CTO would assign tickets to the developers. Communication between the CTO and the developers was mostly through FogBugz – they would ping-pong-assign tickets between each other for clarification, review and test. Even between developers, tickets where assigned with little or no face to face communication.
Developers ran the system on their own machines, but the code wasn’t was deployed to a common test server, so outsiders couldn’t try the system on their own. When the CTO did get a chance to try things out for himself he always found bugs and misunderstandings that were expensive to solve.
Presenting the good and the bad
After three days me and Chris reported our findings back to the group. We suggested that the CTO be their designated product owner, that they use week long iterations and a Scrum-master. The team would push very hard to finish functionality as much as possible inside the iterations, and they would start using a whiteboard to plan and communicate, instead of a bug tracking tool.
1. Designated Scrum Master and Product Owner
2. Use user stories
3. Week long iterations
4. Whiteboard and index cards as communication tool
5. Make reviews and testing highest priority
I think most things speak for themselves. For teams starting to do agile, I almost always recommend one week iterations. It speeds up the learning a lot. Once you feel a little more secure, you can start doing two or even three week iterations.
The company has done a marvellous job at adapting to this agile process. They have a great CTO acting as product owner, who has adapted to his new role very well. Releasing new functionality used to take between five and ten days. Now the team releases every month, and it takes two days. Still a long way from perfect, but much better.
Recipe for success
There are, of course, a number of reasons why it’s going so well for the company. These are things that I will make sure to repeat with our next customer.
1. The management team, consisting of the CEO, CTO, their business analyst and the lead developer, work together as a team. It’s so common that managers play the political game instead of working towards a common goal. Here, they’ve created a team responsible for the change work, and this is a big factor in their success.
2. Involving large parts of the company. For their first iteration demo, they invited the whole office, and had crisps and beer ready. This has created a positive buzz around Scrum. People outside the team are showed how the whiteboard works, and use it to keep track of how items they care about are progressing.
3. The CTO has been successful in shielding the developers from outside disturbances. This allows the team to focus on the work at hand, and on learning how to work in the new environment. Shielding the team is much harder that it sounds. The whole company used to work by harassing the developers into doing what they needed, and now they have to talk to the Product Owner instead. It requires the PO to actively step in and have some tough discussions.
It’s been a fun challenge to help this particular company on their effort to find a better way of cooperation. Changing the non-technical aspects of their process has made a huge difference for everyone, and it has made the team much more productive. In the long run, they have to introduce TDD, CI, pair programming and other technical habits to improve even more.
I’ve changed the look of my blog. Hope you like it!
Also, I screwed up and destroyed the database where me and Chris have our blogs. We had really old backups, and a lot of comments where lost. Also, the RSS-feed will probably go bananas and have duplicate entries.
Sorry about that…
I’ve helped introduce more agile ways of working for a couple of years now, and I’ve always done it by working with the developers. Getting them going on technical practices seemed like a safe bowling activity to start with.
It’s worked fairly well. The biggest strength of starting this way is that a big group of people start trusting me, and that gives me some leverage into other parts of the organization. Since deep down I’m still a developer, I found that the questions that other developers fielded where manageable – it wasn’t that long ago that I asked the same questions.
I’m now helping a client introduce agile practices in the organization, and for a number of reasons, we chose to start from the management practices. We’re doing Scrum, with very few of the agile technical practices. The work is going along fine – actually better than I anticipated. It does feel uncomfortable to stay in management land and not even look at the code (for now).
We’ll see how it goes. The worst that can happen is that I learn a lot.
When you think you are selling, you are actually building a relationship with another person. If you shift the focus from the current transaction and try to strengthen the relationship, the transactions will come naturally. You should always try to build the relationship, not push the sale.
This is my own interpretation of the wonderful book Trust-Based Selling: Using Customer Focus and Collaboration to Build Long-Term Relationships.
There is a lot of things that really resonates well with me from this book. I’m trying more and more to use this thinking when interacting with clients and would-be-clients. I wanted to share how this has changed how I work.
We’re talking to a would-be-client, let’s call them Purple. They have very little experience with agile practices, but they are curious and open. They sent their project manager on a CSM course last year, but very little has changed since – they feel as if they’re under a lot of pressure, and haven’t had time to implement the ideas. Their CTO, Jack, has read a little about agile software development, but has some difficulty understanding all the practices by just reading about them.
We are fortunate enough that we have another client close by, let’s call them Green, that we’ve worked with on and off for the last three years. They use most if not all the practices we think are important. Since the two clients are not competitors, we asked Green if we could bring Purple along and do a little show and tell. Green accepted.
Jack, the CTO of Purple, came to the stand up, and we showed him how the tracking board works, how Green uses CruiseControl, and talked a little about the ideas that were behind this way of working.
Finally, we introduced Jack to Greens tech lead, Carl. We started a conversation, me and Chris from Blueplane, Jack and Carl. After a short while, me and Chris decided that we where only hindering the talk, and excused us. Jack and Carl chatted away, about what the way Green works, and what we had done for them, for well over half an hour.
It was pretty scary – if Jack liked what he saw and heard, it could mean a big job for us. Part of me wanted to jump in and control the discussion, but I realised that this way, we where strengthening our bonds with Jack, and with Carl. Since we had consciously tried to be very honest about our shortcomings and problems, I was pretty sure that Carl would not say anything negative about us that we had tried to hide.
It’s difficult and awkward for me to change the way I think about clients. I try my hardest not to push any sale with them. Instead, my very explicit goal for every meeting I have is to listen to what they say, and try to find something that is a problem for them. If I can, I try to share some experience or knowledge with the person, that might help them with whatever they are having a problem with.
This shifts the focus from me and what Blueplane does, to the person in front of me, and his situation.
This is the first blog post I’ve ever written about selling. Since selling is a big part of starting my own business, it’s something that takes up a lot of my attention lately. I’m very curious to find out what you thought about this post. Please, comment here or send me an email.
The Dreyfus model of learning shows us that people in the beginning of acquiring a skill need more specific guidance than someone that’s more advanced. The same basic idea is applicable to teams. So different teams have different levels of agile competence. One of the things a beginner team might not be very good at is understanding and living up to the prime directive. They have for so long been stuck in a blame-game mode, that trying to learn together is very difficult.
In contrast, a team with proficient agilists will probably work through personal differences and get to the root cause more efficiently.
If you are facilitating retrospectives for a team that’s just starting out using agile principles, you have to take this into consideration. A team just learning to cooperate effectively needs different retrospectives than a team that are well on their way. For a beginner team, the retrospective needs to be focused much more on these types of activities:
A beginner team needs to focus on activities that lead to shared understanding and better cooperation, and doesn’t force the team to make decisions they are not really prepared to. They are not prepared to make these decisions on their own yet. Having them make difficult decisions to early will only lead to frustration and decisions that are not followed through.
It’s still important to make some real decisions in these meetings, so people aren’t scared away by all the touchy-feel stuff. Your job as facilitator is to keep the decisions that the team makes easy ones at first.