Agile leadership: results

A couple of weeks back I have reached out for help for my MSc thesis about leadership in organisations of different size. I have received 200+ responses overall, and 166 complete, usable responses based on which I managed to complete the following report:

Leadership in Agile

A big thank you goes out to all of you who made this possible. Thank you for your time, response and support; I am really thankful to all of you.

Agile != Scrum

“I hate Agile. It’s full of these pointless meetings like planning – which is a complete waste of time.”

I’ve overheard a colleague of mine say this the other morning. Of course, he meant Scrum. Many people think these two concepts are the very same and use them interchangeably. Agile, however, is a much broader category;it contains loads of software development methodologies – one such being Scrum itself. Let’s see a quick (and far not complete) overview: 




The bars above show how heavyweight a process is. The more things prescribed by a methodology, the more heavyweight it is. Scrum is pretty huge; it defines roles, meetings – it pretty much schedules your days two weeks ahead. On the other hand, Lean development only defines principles – like amplify learning – and does not say anything about implementation details.

So if you think Agile is bad (a waste of time, too restrictive, or on the contrary, too permissive), you perhaps just had a not so well chosen process. Take another look, it may worth trying a new agile methodology.

Agility and code quality

Some days ago, I attended a meeting, where different projects’ agile people met and talked about challenges, achievements, stuff. Actually it was not the first time we met. The meeting has been held for months now. For these long months, there has been something that was bothering me about these discussions. I couldn’t name that thing, so I stayed silent, but now I think I suddenly recognized it (under a hot shower, sorry if it’s TMI – too much info). After these months it seems to me that people percieve agile as daily stand up meetings + retrospectives (or just the first one, in case of Kanban development). Some of these people are amazed that they’re still getting bug reports in spite they “are doing agile”. Standups: check, retros: check, planning meeting: check, but bug reports, however, still flowing in.

Don’t get me wrong, I’m not against these things. Daily standup is a very important thing. It facilitates communication between team members, or sometimes even between different teams. Daily scrum alone, however, will not make code quality any better. It will strengthen team spirit, it will help everyone to keep track with every aspects of the current development, but it’s not meant to get source code in a better shape.

The same applies to retrospective. It is a very cool forum to talk about strenghts and weaknesses of a team. Even better if constructive ideas arise (by the way, I don’t understand why some people think retrospectives cannot fit into Lean/Kanban ways of working. The process itself can be trailored and developed; for new teams it can be particularly helpful). In my opinion retros are one of the most important meetings of agile frameworks. It’s psychology, I guess. Some people simply won’t tell their ideas, unless they are told to do so.

So, standups and retros (along with other meetings) fail to improve code quality. That’s because agile ways of working  can be divided into two parts:  the process itself and a technological part. The process part mainly contains of the meetings described above, definitions of done, team rules, team members’ motivation etc. One needs soft skills in order to manage/take care of these things. By soft skills I mean empathy, friendliness, motivational skills etc. And all these things will not get you a good quality product. It’s because quality is directly related to technical skills. Technical skills include test driven development, code review, pair programming, design discussions and so on. So, will code review help improve quality? Most probably. You might spot suspicious code lines, liar names, uncovered production code. Will TDD help? Definitely. Your code will be doing exactly what you expect it to be doing.

I once heard of a project where all the soft skills were perfectly applied. All staff members were happy with their work, they have had daily scrum, retros, everything. However, when it came to unit tests, they were like: “well, uhm, our unit tests require a living connection to the database, a writable file system, a network connection …” and so on (remember the definition what does not count as a unit test: a test which touches the file system, talks to a database or over a network. Anything that lives outside of the test runner framework). So even if these guys respected all the soft-skill related part of agile, were producing not so good quality. They were stuck at a low level of technical skills.

So what I’m saying; it makes no sense to apply only one or the other part of an agile dialect in solitude. You need both of them in order to succeed. Soft skills in order to get motivated and happy people, and technical skills in order to produce fewer bugs and maintainable architecture. No process hsould be called agile until both parts are applied, in my opinion.

Agile development and UML

In case of agile development, we usually don’t run into hundreds of lines of documentation, with detailed diagrams, architecture proposals etc. This is good for several reasons; developers can use their creativity in order to materialize requirements. This way, people won’t fall into the pitfall of blindly following someone’s vision either.

However, UML may become in handy at feature development. With just a small investment (as low as the price of a whiteboard) a team can boost their productivity. This is how: promote a whitheboard as “design board”. The design board has no other role, than to store the current architecture of the feature under development. It, of course,  supposes that each and every team member updates the board whenever they make a change to the current state.

One might argue that there are a lot of software tools out there, why not use those? Well, the answer is simple; people are lazy (and forgetful, in the same time). Even if the UML diagram is stored somewhere everyone has access to, they won’t open it, let alone update it. They simply forget it, becouse the thing is not in front of their eyes all day long. However, if it is present materially, people actually tend to update it on a regular basis (also, daily standup meeting is a really good period to remaind everyone to do so, in the case they somehow forget it). The diagram doesn’t have to be that detailed. It’s perfectly enough if it contains the classes and interfaces, associations (uses, implements, extends …) and main methods.

How does this help increase velocity? Simple. People don’t have to randomly open different classes in order to find the right one to place some new code in. They just take a look at the board and know immediately how classes are related, which is the right one for the new logic. They also don’t have to remember all the class names and the relationships between the different components. Planning meetings (along with task breakdowns) will also get shorter. It eliminates the phrases that start with the infamous “well, I guess…” stuff; people will talk about facts not beliefs. Less stress, less time spent on arguing.

The team leader role

A couple of weeks ago I had the opportunity to participate on a workshop held by Jurgen Appelo (XP2011, Madrid). I like these kinds of “shows” (and by show I mean workshop); it’s not about the talk only, but the audience’s involvement. It’s always exciting to learn something through funny events and games.

This was the first time ever I played this cool game, called delegation poker. In short, there’s given a group of 4-6 people; they are taking turns in telling stories. At the end of the story, each and every player has to decide upon one of the seven levels of delegation they think fits the best (for a more detailed description, read the original document. Really, you should try it once, it’s fun!).

What actually amazed me in this game, is people’s different view on the very same concept. I was part of such a group, and here are the stories and delegation levels we had (let’s denote different people by letters, names don’t matter after all). You’ll see that all the stories are targeted at the team leader’s point of view.

Story #1

There is given a newly set up team. They are quite new to TDD, XP and generally, to all agile techniques. From a team leader’s point of view, what level of delegation should be used in order to facilitate pair programming?
A: Level 7, ‘team members should decide whether they want to pair up or not. As a team leader I don’t care about pair programming as long as they deliver quality’
B: Level 6, ‘let the team decide about this, but I would like to have some feedback at the end’
C: Level 4, ‘team leader should be considered as part of the team. As long as they are taking part in coding, they should be treated as any other team member’

Story #2

Let’s say you are a team leader. You lead a cross functional team of experienced people. You have the possibility to choose what methodology you want to follow: Scrum or Kanban.What’s the delegation level?
A: Level 6, ‘I was wondering whether this is a six or a seven. The only reason I picked six is I really would like to have some feedback on this. This is an important decision, so I would like to be involved in it.’
B: Level 2, ‘I would like to make sure we follow the methodology I consider best. So I can protect my team better, and can shield them from the pressure from upside.’
C: Level 5, ‘I would tell some  pros and cons of both. Then I would have the team decide which one would they rather follow. I want to make sure we apply the techniques the whole team believes in.’

Story #3

Again, we have a team of experienced developers. What delegation level would go best when deciding about punishments for the ones being late to standup meetings.
Guess what, we all went with a five to this question. It was the first and only story when we all agreed upon the very same delegation level. We all thought the team leader should have some influence on this one -like insisting on having punishments- but not in a command and control style.

And that was the point when we run out of time. There was no more time for situations and/or discussions (unfortunately, I would say). I don’t even know what would be the definition of a team leader based on the stories above. Is a team leader a proxy who makes the management pressure vanish (#2)? Are they the ones who tell people how to do their job, based on best practices (#2)?  Or persons who feel they really are part of the team when it comes to important decisions (#1)?

As I see there are two “schools of thought” here fighting; the first one considers the team leader rather a manager, the other thinks team leaders are rather team members (who “manage” their teams seamlessly). The question is, which perspective is more useful from the team’s point of view? (provided that, there really are team members who are dependent on their team leader. These are the persons who keep asking “what task should I do next?”)

Anyway, no conclusions drawn; I guess one cannot clearly state which one is best. It was, after all, a very good experience, and a very good lesson on different people’s different visions. You are welcome to share your thoughts.

Agilizing an organization, a first step

At the company I work for, we have several project roles, namely :

  • System engineers
  • Software engineers
  • Function test engineers
  • I&V

A story that happened to my team in the past has made clear that traditional ways of working need a bit of revision.

One day, adding a new feature was decided by our product management. It was quite a big feature, with a lot of coding, innovative solutions, automating parts of an existing system. In our company, the life-cycle of a feature starts at an implementation proposal-writing phase.  These proposals are actually sets of requirements, coming from our “customers” (we don’t have customers in the traditional meaning of the word, but anyway, it doesn’t really matter. Although I know that documenting requirements is not part of the agile framework, this document is really needed due to the lack of “real” customers). Our system engineer has come up with a proposal, that at some point, stated – the system shall somehow distinguish between different categories of objects.

The document was then handed over to design people. They started to find out how those objects should be distinguished. After several brainstormings, design discussions and debates it was decided that a best solution would be a new GUI element, namely an extended capability-table. However, swapping the old table with the new one took a lot f time. New methods were needed to be introduced to make the table compatible with the old implementation. This automatically generated a two weeks lead time, which also made the management a bit upset.

Finally, the implementation was ready, the increment was passed on to be function tested. Guess what happened; the new table was incompatible with our automated test cases, resulting in a (!)one month lead time. A whole team needed to be allocated to fix the broken test cases. Managers started crying, release date was postponed several times.

So we drew the conclusion that both design and function test should be somehow involved in requirements gathering. In a meeting of just one hour, we decided that:

  1. From time to time a little internal document review (thanks for the term, István) will be held; Designers can ask questions here, share opinions, give voice to doubts etc. Such a way everything written down in the document can be reconsidered before anything is made final. These meetings can generate prototyping and analysis tasks, in order to clear technical doubts.
  2. Component prototypes will be created by a couple or more designers. In order this to be successful system people will attend standup meetings. Short discussions will be held; system can answer “daily questions”
  3. There will be created a prioritized backlog for prototypes. The backlog will be administered by product owners (=system people), and will be reorganized in every two weeks.
  4. Function testers will also be involved in document elaboration. They will create automated test cases and stress tests for the above mentioned prototypes.
  5. Design people will be given the opportunity to take part in splitting work items into user stories.

The next implementation proposal will be written based on the action points above. We expect that more tricky details will be uncovered, making design and testing more fluent. We’ll see…

The super TDD pen

Today I have introduced my colleagues the “Super TDD Pen”. As I’ve mentioned earlier, most of these guys have never met agile, test first, scrum, kanban etc. before, so they need to practice and practice and practice even more. The most important thing before we start implementing business logic, is to catch up a bit with test driven development. In order this to happen, I take different approaches: organize code katas, discuss agile design values, send them articles to read, and the newest: The super TDD pen. It is nothing particular, just an ordinary marker we use to annotate tasks solved in TDD. I also updated the DoD (definition of done) to contain a reference to the red pen.

I considered it important to present the pen at the time only GUI mocks and prototyping tasks are present on the whiteboard. Of course, one can argue there is not much TDD involved in this phase of the project, but anyway; I hope they get a bit frustrated by the lack of red pluses, so they start writing code test first.

On the other hand, it will be a good marker how widespread TDD is in our project. I also plan to analyze task PostIts on a regular basis, so we can see the progress we make. I hope to see we are getting better at it, so we can place more emphasis on other important things too.