Next week I am presenting at two conferences: the 8th edition of 4developers (Warsaw) and the 7th annual ACE! conference (Kraków).
Together with Mariusz Sieraczkiewicz we will talk on “How To Transform Good Teams Into Awesome Ones”. We will share our experience from Agile transformations we worked on recently, including success and failure stories. Join us to learn the model we use and the steps we make while working with the teams.
See you in Warsaw or Kraków.
-Paweł
PS I will publish the slides after the conferences.
Thank’s to Toruń Java User Group my presentation on working remotely and distributed teams has been recorded. Video and presentation slides (both of them in Polish):
There’s no point in driving faster in the wrong direction.
That’s why staying focused on what really matters during the whole the software development process is crucial. Which means killing features that no one is going to use, shortening discussions and brining them back on track, and helping teams with difficult decisions (“Should we refactor this piece?”, “Should we allow deleting users?”, “What to work on next?” ) – I must admit I really enjoy this process 🙂
I gave a talk on this topic during the last AgileByExample 2014 conference. Here you’ll find the video:
I was recently asked “What is more in Kanban than a Taskboard and WIP limits”? Actually, there is a couple of tools that may help your Team become even more effective:
Discover Your Real Developement Process
Your Kanban board doesn’t have to be as simple as this:
It may look like that:
It all starts with a process of Value Stream Mapping, which later helps you craft a Kanban board corresponding to your process. Discovering a real development process is an insightful exercise itself – it helps the Team realise it’s more than “Pick a task, code and hand over to QA” 🙂
Measure, Chart and Improve Your Flow Efficiency
Cumulative Flow Diagram helps you look at your flow from the brid’s-eye view. As you can see here it’s a single chart that brings quite a lot of information:
That’s why when it comes to measuring and analysing average Lead and Cycle Times I prefer to look at the Control Chart that graphs these numbers for each task, like this one:
It might be interesting to analyse which tasks (and why) took significantly longer time to complete than usual.
Flow Efficiency
Another interesting measure in Kanban systems is Flow Efficiency, which is basically:
Let’s say you start working on a feature on Tuesday morning and finish it a week later. Usually, what happens meanwhile during this week is a number of activities not adding value to this feature like:
waiting – e.g. waiting for graphics design, translation or QA
multitasking – working on other items.
If the actual time spent on this particular feature by the whole team is 2 days, then the flow efficiency for this feature is 2 days (work time) / 7 days (time passed) = 28.5%.
Other Tools and Measures
These are just few examples of tools and measures related to Kanban. I haven’t mentioned Classes of Service that help you handle urgent and fixed date issues as well as Cycle Time Distribution analysis that helps you define Kanban Service Level Agreement.
What do you find useful in Kanban beyond a simple Taskboard and WIP Limits?
That made the decision to leave an extremely hard one, but I feel it’s now time for me to look for new challenges. I have decided to leave SoftwareMill for two main reasons:
1) More face-to-face interactions
Over the last years my focus has moved from programming to organisation and leading and coaching people. In short – more talking to people, less talking to computers 🙂 I really enjoy it, but it’s much harder to do remotely, which is why I want to go outside my home office.
I’ve been really enjoying working remotely for a long time. It has a number of benefits and I’d love to keep them. But since I’ve discovered how much joy face to face conversations bring to my life I want to have more of them.
2) New challenges for my personal development
SoftwareMill is doing great. There are, of course, things to improve here and there, but staying there would be staying in my comfort zone.
To say I’ve learned a lot at SoftwareMill is an understatement. I’ve learned something from everyone who I worked with. I’d like to say a huge thank you for all the time we spent together, all the conversations and ideas we had. You guys are AWESOME. I am keeping my fingers crossed for your efforts in making SoftwareMill the best place to work for IT workers.
What’s next?
I am taking a short break for a while, but I am open to proposals for collaboration – short or long-term.
My passion is helping teams and individuals to discover and focus on what really matters for them. I enjoy working with teams and on the business side of IT. And in all of this, I aim to make myself dispensable by encouraging self-organisation.
I have experience and a lot of passion to work in two areas of software development:
1) Building effective, self-organising, motivated teams
either as an Agile coach, trainer, facilitator
or as a servant leader a.k.a. Scrum Master
2) Bridging the gap between business and IT (and users)
as a Product Owner, Product Manager, User Experience specialist or all of them at once 🙂
So… if you think we could do something awesome together or just want to talk, ping me via e-mail, Skype (pawel.wrzeszcz.work), LinkedIn or Twitter.
“Distributed agile is hard” is what I often hear. And yes, after working remotely in various distributed teams for 8 years, I agree. But I am going to argue that this is a good thing.
Basically I believe that working in a distributed environment is like using Scrum – it does not solve your problems, but makes them more visible. I like to call this a “visibility shift”.
With the challenges being more visible, a distributed team can actually make it easier to adapt an agile approach to software development. Especially if it is a team where everyone works remotely (see “Remote Worker, Distributed Team”).
Value vs. presence
Working remotely makes it harder to verify whether someone is at work all the time or not. You cannot look around you and see other people sitting in front of their computers or having discussions.
And this is good. Because without this notion of presence, something else becomes more visible: the actual value delivered. Because at the end of the day what counts is not the fact that we have been to work, but the new feature or a fixed bug.
(Just to be clear: I am not saying that value delivered is not visible in the co-located environment. But in the distributed setup it is one of the very few visible signs that someone was at work. Which is great because this is what agile is all about – focusing on value.)
Communication challenges
If your team suffers from poor communication or endless meetings, working remotely will make this even more conspicuous.
It is really hard to stay awake during a long teleconference meeting. And this is good. Because it shows how useless meetings are in general. And by working remotely you will have less of them, in favor of more asynchronous communication.
Trust issues
Another thing that becomes painfully visible in the distributed setup is lack of trust.
I heard this statement from a manager on why distributed teams are hard for him: “Sometimes I have to go in person to make sure they are doing what they are supposed to”. Others are worried about their employees browsing Facebook instead of working. These are all signs that the level of trust in the team is low. And yeah… such a team would have a really hard time working in a distributed model, because the trust issue would be even more visible.
All in all
So yes, distributed teams do face challenges. But they face them because things that matter, like value delivered, communication and trust issues, are more visible to them. Which is good, because making an issue visible is the first step for improvement.
Agile Pricing – Consider models like Pay Per Feature, cause neither Fixed Price nor Time&Materials are good billing approaches (e.g. T&M does not encourage productivity).
Ideally, a Product Backlog should give the whole team a clear roadmap on work to be done.
I remember times when I actually believed this is really possible, even with a huge Backlog, but in practice in every project I worked on I struggled with keeping the Backlog up-to-date, prioritised and consistent.
Then, thanks to Roman Pichler (see Top Ten Product Backlog Tips for example) I understood that the Product Backlog requires a lot of care (well, the same way like codebase does). This includes:
Finding right wording for user stories
Writing acceptance criteria for stories
Managing stories on various level of detail, decomposing them when necessary
Removing(!) no longer valid entries from the list
Rewriting other ones
Getting stories estimated
Prioritising
and that is probably not the end of the list.
All of this done regularly!
Woow, that is a lot of work!
Reality
In practice, most of Product Owners or people responsible for Product Backlog (including myself) do not perform most of these tasks regulary, because the only really important horizons (at least in agile/lean approach) are:
This iteration/week
Upcoming release or other important date, usually within a couple of weeks from now
This means that what actually matters is on the top of the Backlog. All other stories are… well… you can either say “less important at the moment” or, I believe more correctly, “waste”.
Hovewer, over and over again I observe the following scenario:
Customer: Hey, could we have feature X in our product?
Development Team: Well… it all depends on your priorities.
Customer: Yeah, this X is really important.
Development Team: OK, in our Backlog next things to work on are Y and Z. Should we do X before?
Customer: Ah, no! Y and Z are crucial too. Hm… Maybe we could implement X immediately after Y and Z?
Development Team: Yeah, sounds like a plan. Although we will still have several important things to do after Z for the upcoming release, so we will have to see how X fits.
(silence…)
Development Team: OK, let’s put X to the Backlog and we will see.
And you know what? Quite often this X stays in the Backlog forever.
This is what I call saying “Maybe”, instead of “No”. Backlog is a safe option to close such a conversation, but unfortunatelly later on no one dares to remove anything from there, so lower part of Product Backlog becomes Idea Trash.
Possible solution
Here is what I suggest:
Keep very small, focused “Backlog” (better name “This week” or “This release”)
Put a hard limit on number stories in it. In other words, limit WIP, where story in the backlog is also considered as “in progress”
Anytime you are tempted to break the limit, remove less important stories from the Backlog
Most importantly: Have a clear working agreement that removing an item from the Backlog does not mean rejecting to do it at all. You can add such a story later when it becomes important enough.
I am using such an approach on my Personal Kanban board and I would love to give it a try in a project. Actually, this post is triggered by our hassles with managing Backlog in Codebrag and by writing my thoughts down I hope to convince my teammates to give it a try 😉 [update: We have tried it in Codebrag and it works very well]
The idea behind this is making an issue of “There is always more to be done than our capacity” more (frequently) visible. I believe that having a clear backlog helps having clear mind and making better decisions.
The argument against this approach I hear mostly is that something important or innovative might be forgotten if not written down. I disagree. If a user story really “loves” me, it will come back. Otherwise it is not worth my effort.
Both of them changed my way of thinking (and a perspective from which I think:)) about myself and the world around. I hope you enjoy them as much as I do.
See you in Warsaw or Kraków.
pawel.wrzesz.cz 