Marek Blotny's Blog

I see daily stand-up meetings (“daily scrums”) as a one of the most beneficial practices in SCRUM’s repertory. Theory says that during the daily scrum each team member should answer three well-known questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

Daily scrum is a great example of small things which make great difference. Three simple answers from each team member ensure that entire team is on the same page. It’s clear who is working on what, what will be achieved by the end of day, what problems we have etc.

What I find strange is that theory doesn’t leave much room for any discussion during the daily scrums. Discussions should take place during the follow-up meetings, immediately after the daily scrum. In general I agree with this rule. Bigger issues which don’t require entire team can be talked through later.

But I think it’s much more beneficial for a team if all members are allowed to jump in anytime during the daily scrum to add anything they find helpful. I have seen many scenarios where such impulsive hints work very well. Although scrummaster has a tough task with keeping the discussion under control. On the other hand the worst thing which can happen is when team members are in ‘on hold’ state until it’s their time to speak. That kills spontaneous knowledge sharing and potentially turns daily scrum into a progress report with limited profit for a team.

It’s vital however to keep the meeting under 15 minutes and stay high level. There is not enough time for the team to go into each and every detail. That should happen during the follow-up meetings. Scrummaster responsibility is to ensure that discussions are on reasonable level.

So if you ask me if enforcing so rigid structure of daily scrum make sense. I will answer … definitely not! On one hand you have effective and useful daily scrums which encourage teamwork and on the other quite rigid structure and doing everything by the book. I’m far from saying that traditional approach doesn’t work, but it can be improved, so for me it’s a simple choice.

What’s your view on this? Do you think it makes more sense to follow traditional rigid structure of daily scrums?

In one of my previous posts Are ex-developer good project managers I was exploring one of a few possible career paths for developers. Post was mostly about evolution from developer to project manager and how development background can help in new role. Under this post Pawel Brodinski left a thought-provoking comment:

I have one great idea for developers who want to transit to some other position: become a tester.

I didn’t consider this path as viable option mainly because it’s not a very popular trend. There was always an obvious gap between developers and testers. I do remember people talking that Microsoft “converts” poor developers into testers… I don’t know if this story holds the water but I’m sure stories like that bear in people’s minds. And it makes transition to tester less desirable, at least from developer point of view.

I believe that both professions require different mindset. Developers are accustomed to a joy of creation; their work requires creativity, and in the same time gives a lot of opportunities for instant gratification. If your new class or method work then great, you are done. It’s easily achievable and very positive.

On the other hand testers are not building anything, they have to verify that things built by developers work as expected. On a basic level this inevitably involves going through a checklists to make sure that (for instance) html renders correctly in all browsers. Repeating such steps over and over is not something that most developers would like to do.

But there are also similarities between both professions which gives ex-developers some benefits.  Advanced testers don’t have to go through checklists and check everything manually, in most cases it can be automated and this is the place where pure development skills are very handy. Another advantage is creativity which is a requisite not just for good developers but also for all good testers. Figuring out all possible scenarios in which given functionality can be used, checking all available paths; digging as deep as it’s possible – without creativity it’s hard for good outcome.

I agree with Pawel that good tester can be “well worth the bigger money than they coding colleagues”. Tester which is able to reliably verify that software works is invaluable. Testers who are familiar with typical development pitfalls are able to relatively easy find all edge cases; it makes them priceless members of any team.

What about instant gratification? This is essential thing which keeps developers happy. Do testers have something like this? I don’t think so … and this is what makes those two jobs so different and transition from one to another so hard.

Difference between running and managing a project is not negligible. You may think that this is just a wording issue and both alternatives mean roughly the same thing. But that is far from truth. Seth Godin is saying that running a project is “an active engagement, bending the status quo to your will, ensuring that you ship”. You are only managing a project if your concerns are limited to:

• Tracking progress
• Generating weekly reports for management
• Taking care for resourcing side of a project
• Resolving blockers for your team

I’m far from saying that the above objectives are useless or ease to achieve. However I see them as a starting point for any PM. If you are good at it, then great, but to become a really good manager and run projects you need to do a lot more:

• Keep an eye on project’s scope and make sure that it’s not mounting
• Look for bottlenecks in your team and eliminate them
• Make sure that there is a good communication between your team and a client
• Do whatever you can to verify frequently that your are building the right thing, that this is what your client needs
• Identify problems which may prevent your team for shipping and resolve them – “bend the status quo to your will”
• Make sure that your team knows exactly what is expected from them in all phases of a project

Seth wrote: “Running a project requires a level of commitment that’s absent from someone who is managing one” To run a project you can’t spend all day adjusting Gant charts in MS Project. You can’t sit all day in JIRA or Excel spreadsheet. You have to move your ass and talk with people, talk with clients, be active, be a leader. You have to leave safe waters and put yourself on risk.

What can you gain? Seth gives the best answer: “Who would you rather hire, a manager or a runner?”

I have been watching Cory Foy’s presentation yesterday. The presentation was about ‘Growing and Fostering Software Craftsmanship‘ but for me the most striking part was when Cory was talking about knowledge sharing and about Bus Number. Bus Number Wikipedia defines in a following way:

Bus Number is the number of developers on a project who could be removed before understanding of a particular part, or all of the codebase would suffer severely. The term refers to the fact that if these developers were unable to work on, or consult for, a project it would be difficult (or impossible) for new developers to pick up where they left off. In other words, if the developers were hit by the proverbial bus, the project would be in jeopardy.

So it’s pretty much clear that we want Bus Number to be as high as possible. We don’t want to see our projects to be so vulnerable. With low Bus Factor one unexpected event can lead to serious problems.

And here comes the most interesting part, Cory claims that in most organisations this factor equals exactly one! Think about it for a second … it means that entire project is in trouble with one person taking a new job, having a health problems or being hit by a bus. How bad is that?

Another point made by Cory – most organisations are not promoting knowledge sharing. Rewards and fame go to the people who know how to rescue projects, who are able to deal with complex projects, difficult clients. Knowledge sharing is not that high on the list, as a side-effect people don’t pay much attention to it.

I think usually people will agree that knowledge sharing is an important thing, but in the same time people tend to focus more on urgent things rather than important. As a consequence typical ways to share knowledge like code reviews, pair programming don’t happen very often.

What is the Bus Number in your organisation? How do you ensure knowledge sharing? Who should be the most interested in increasing Bus Number within a team? (PM? Tech Lead? or maybe someone else?)

Sooner or later developers have to start thinking about their career path. They are facing a question like ‘I have been programming for x year … now what?‘. As I see it there are three potential career paths for developers:

1. Well known path from development to project management
2. Purely technical path towards “senior developer” / “technical lead” / “software architect”
3. And finally third path towards technical consultancy

Quite often you can hear that developers are not good project managers. People say that mainly because being a good developer doesn’t make anyone a good leader or project manager. Programming and management require different set of skills.  Majority of developers got technical training and they lack soft skills which are essentials when it comes to managing people. However developers want to “progress” and in some companies this is the most natural way, the most obvious path. Transition to manager requires learning new competencies and changing “point of view” but for sure it’s possible.

Assuming that ex-developers feel good in the role of project manager  they have one big advantage over non-ex-developers PMs – they know what debugging is!

Every software developer knows how to debug code. When something goes wrong they can figure out what the problem is. Once the problem has been identified, they can figure out how to fix it. (In most cases.)

Ex-developers understand software creation process inside out. That puts them in much better position to investigate problems which may occur and solve underlaying issues. For them project is not only about tasks, estimates and tracking progress. They know what is really going on. PMs without technical background usually have following options when the project is in trouble:

• additional people to speed things up
• overtime hours
• functionality descope

Ex-developers are not limited to the above list, this is their strong side!

Yesterday I was on an interesting call with a client. Project for this client is on hold for a while now. At the beginning it was a project like any other, but after one or two sprints a list of blocked user stories started to grow really fast. After the second sprint it was already clear for us that decent cooperation of both sides is a must if we want to have a chance to meet the deadlines. We were very clear about that with the client. Unfortunately client didn’t have time to work with us so we decided to stop entire project, people were moved to the other projects and basically we were waiting for the client to come back to us and unblock further development.

That was the situation until yesterdays call when the client promised to remove all blockers and asked us to immediately restart the project. Our answer was that of course we are happy to restart the project but we need x weeks to get developers back from other projects. Therefore immediate restart is not possible.

The point which I want to make here is that this example illustrates well healthy balance of powers between the development team and the client. At the beginning of the project we have committed to deliver before the certain deadline but it doesn’t mean that entire responsibility is on our side. We have an obligation to finish our work within agreed timeframe but in the same time client has an obligation to support development team and find time to answer questions. When client is neglecting his/her part of the deal then we have a right to stop the project.

On the other hand when client is asking for project restart (s)he can’t expect that it will happen immediately. We are partners therefore client has to accept that it’s not our fault that project is on hold and we need time to assemble the team back.

It might be obvious for many people but I have also met number of people who have only one answer to client’s requests: “sure, no problem”. Answering always like this is risky because it goes against the balance and suggests to the client that we are not partners.

Adopting agile methodologies doesn’t guarantee success of each and every project. Sometimes you can have absolutely great team, skilled and well motivated people, flawless development process and yet project can be a total disaster.

How can that be? Prerequisite for all projects is a product backlog (requirements specification). If user stories (requirements) are vague and scope is blurry then probably this is classic garbage in, garbage out scenario. In such scenario a single team with no external dependencies and good cooperation with a client has a slim chance to succeed. But in projects, with number of different teams involved, there is absolutely no way to produce something else then garbage.

How to avoid garbage in, garbage out scenario? Before giving a green light for a project ask yourself a few questions:

1. Are requirements documented? – you don’t need each and every small detail, but high-level user stories are a must.
2. Are requirements clear and explicit? – requirements should be put in simple words without any ‘marketing talk’ but also without technical details.
3. Is scope for your team well defined? – this is about clear responsibility boundaries. You want to know what your team is supposed to do; also you want to know which team should help you with your external dependencies.
4. Do you understand goals for a project? – what is a business justification for this project? What client wants to achieve?
5. Do you understand the most fundamental user stories (use cases) of a system? – do you understand how system should work? How complex the features are? How many internal/external systems will be involved in building each feature? For each feature – what are the responsibilities for your team?
6. Do you have access to the product owner/client/stakeholders to be able to ask questions? – For sure you will have some questions, you will find some edge cases therefore you want to have access to someone who can make some decisions and conclusively answer questions.

If answer to at least one of the above questions is ‘no’ then you have to be careful because quality of project’s specification is substandard. Of course you still may want to take a chance but be aware – it’s a risky game.

What does it take to advance from junior to senior developer? The most obvious answer is experience. But is it only that? Or maybe number of years of experience is completely irrelevant?

According to “What makes a programmer ‘senior’?” post, years of experience are not so vital, senior developer should have following qualities:

1. You know more than one (programming) language
2. You regularly code outside of work
3. You’ve built software from conception to implementation to support
4. You innovate
5. You apply software to solve real problems

I definitely agree that practical knowledge of more than one programming language gives broader perspective. I also agree that experience from each step of project life cycle is absolutely essential. Especially beneficial is spending a bit of time on support and learning on your own mistakes. That is supposed to be a time where you learn what is needed to design code in a way which is easily maintainable and open for extensions.

I can’t fully agree with the second point … not everyone has time to contribute to some open source projects, I can agree that this is nice to have quality but not essential. But is that all? Or maybe something else can be added to the list? Personally I would add two things:

1. Senior developer should have skills and knowledge on techniques and tools required to guarantee satisfactory application performance. This is not only ability to use load testing tools and profilers but it’s also about finding application bottlenecks, making sure that application scale properly etc.
2. Second thing is about right attitude – I expect from senior developer to be proactive, to be able to think about the work on a high level, to constantly strive for high quality solutions and at last to take a lot of professional pride in his work.

Each project, each experience should be an opportunity for each developer to learn something new and in that sense number of years of experience helps. But bottom line is … to advance to senior developer you can’t just focus on coding, you need to constantly develop your skills and seek ways to wider your experience.

There are scenarios where story points can be very handy and using them is beneficial. But before I move to that, one thing has to be clear:

Like it was stated in my previous post “all that business care are man-days and how many is needed to get things done”.

So it’s essential to establish mapping between story points and time, something like this:

1 SP = less then 4h
2 SP = 4 hours to 1 day
3 SP = 1 to 2 days
5 SP = 2 to 4 days
8 SP = 4 to 8 days

It’s important to remember that points are estimates so mapping story point to a single integer is like chasing rainbows. Estimates should be represented by ranges and the same goes for story points.

As a result of this approach engineering team should be able to say for instance that they need 10 to 20 weeks to deliver a project.

Of course at this point range is quite wide. There are a few options to do something about it:

• use historical data for similar projects to compare estimates and the actual time which was needed.
• ask experienced members for an opinion – they might tell you straight away that there is no chance to deliver in 10 weeks.
• simply assume that optimistic scenario (10 weeks) is not very likely

The best part is that after each sprint you will be able to predict more accurately how much more time your team needs to deliver. Even after first 2-3 sprints you should be able to say if you are close to optimistic scenario (10 weeks) or pessimistic (20 weeks).

Story points are about relative size of work

In one of the comments under Mike Cohn’s post I have found great example for usefulness of story points:

One of the most compelling reasons to prefer story points even though it is another way of estimating effort is because it allows individuals of different skills to discuss the relative size of work. My favorite example is of two runners at the start of a trail–one says it will take 5 minutes to run, the other says 10 minutes. Both are right. Those are the amounts of time it will take each to run. There is no time-based argument they can have to settle on the “right number.” However, both can agree that some other trail is twice as long—one runner will be thinking “Yep, 20 minutes” and the other will be thinking “Yep, 10 minutes.” But both can agree “twice as long.”

Using story points to estimate enforces team members to focus on discussing relative size of stories. They just need to define some reference story (for instance worth 2 story points) and other stories compare to it. This way team members don’t wast time arguing about exact number of hours. Story points are not so fain-grained. For mature teams this approach should be much more efficient then estimating directly in hours/days.

One final thought … it’s probably good idea to use story points to estimate user stories but be aware that people might have very different view on what story points represent. Make sure that all members of your team understand story points in the same way.

Concept of story points was always slightly confusing for me so I wasn’t that surprised after reading Mike Cohn’s blog post and comments that definition of story points can vary widely between different people, here a few examples:

• SP should be based on the complexity
• SP is a measure of complexity, effort, and doubt
• SP is a way to measure the size of the requirement, not the time it takes to implement the requirement
• SP are not about the complexity of developing a feature; they are about the effort required to develop a feature
• SP are “size points” and map to time retroactively
• SP do not *equal* hours because points are an estimate
• SP are an estimate of effort (“how much time will this story take?”)

It’s strange that concept which is part of agile planning and estimating for so long can be so confusing and can be understood in so many (sometimes even contradictory) ways.

Maybe definition of story points should be agreed within each team separately? In a similar way as it should be done with definition of ‘Done’ for user stories? Then for one team story point means X and for other team Y?

Personally I don’t think it’s a way to go. Ultimately after planning session we, as a engineering team, are suppose to answer one fundamental question: how much time we need to deliver the project. Therefore it doesn’t matter if you estimate in story points, ideal days, ideal hours or something else. Final outcome has to be in man-days.

If all that business care are man-days and how many is needed to get things done than maybe there is absolutely no point in using story points? Story points are confusing. Maybe we should estimate in man-days and get rid of this additional level of abstraction? I will try to answer that in my next post …