We can't finish our stories! Help

You have a great team, that works hard and uses the best IDE of the market and the chaps do talk to each other; and still you they can not manage to finish the stories they have in the sprint backlog.

Seems to be a well known problem? If so, just try to answer the following questions:

- Do you have a detailed sprint planning?
You should have! And for a 4 week sprint, it should be at least 4 hours. Just an hour is not enough for that.

- Does your product owner prepares user stories for the team, with some estimation beforehand?
If she does, please take care that the team not sees the estimations of the PO. They would just influence the own estimation and might lead to untruthful commitments.


- Is the product owner really available for the team, through the whole sprint?
Take care about it. The team might have questions during the development. If they need to interrupt frequently while the product owner is not available, the story will possibly fail the sprint. Or even worth, if they develop something that is not accepted by the product owner (afterwards notabene).


- What is the average size of the user stories that are selected for the sprint?
If you feel that stories are two expansive, than consider splitting them. There are some good techniques that might help you. By splitting of stories, consider fulfilling the INVEST criterions. Another good article on this topic can be found here.


- Do you have an exhaustive DoD for your stories?
If the answer is no, than you have an insufficient sprint planning! It is of immense importance to have a well defined exhaustive DoD for each story. It helps to negotiate it with the PO. Even more important is the discussion about the DoD. Many questions and potential problems can be covered up by discussing the list.


- Is your team really committed? What is the commitment of the sprint?
It is helpful to have an overall goal for each sprint. A commitment such as: "We are going to finish all the stories selected for the sprint" is pretty much senseless. You should have something like: "With this sprint the user should be able to create and manage his profile" or it can be some nonfunctional requirement that has some impact on the user experience: "With this sprint we are going to improve the responsiveness of the GUI application." Print it onto the Story board to keep it in mind all the way long. Time to time, it can be helpful to ask the team, how they feel about the commitment.

Comments on code comments

Some easy topic for saturday evening!

Please do not comment your code!
Or do it less than you do now!

I know you have learned that comments are good, and yes, I was very happy to see lots of comments in an assembly code, but please, do not comment each line of your java code.

Consider the following snippet:

1  /**
2   * This method calculates some value.
3   * @param stockId stock identifier
4   * @return integer value
5   */
6   private int calculateSomeStockValue(int stockId) {
7       // the initial value of the algorithm
8       final int initialValue = 10;
9
10      EntityManager em = null;
11      try {
12          // create an entity manager to access the database
13          em = this.managerFactory.createEntityManager();
14          assert em != null;
15
16          // read the stock from the database
17          final Stock stock = em.readStockValue(stockId);
18
19          // if no stock found return the initial value
20          if ( stock == null )
21                return initialValue;
22
23         // retrieve the average price of the stock
24        final double stockPrice = stock.getCurrentPrice();
25
26         return stockPrice;
27      } finally {
28             // close the entity manager if not null
29             if ( em != null )
30                 em.close();
31      }
32 }


Just be honest, what additional information gives you those comments? I mean in spite of the fact that they make the code unreadable, and they are probably even false (see line 23,24 - is it a bug in the source, or just an old comment)!


Do not comment your code, or if you comment it consider writing useful information! Rather then use speaking variable and method names. Don't be afraid of long names. Your code will more readable through them.


Less comment is more!

More on hierarchical scrum teams

Software development can make so much fun! One of the big idea behind scrum, is to enforce a face to face communication in the team. To get the power of the community, through the whole development lifecycle. For me it was one of the main arguments to start working with scrum. A really good team works much more efficient, produces much better code and of course software quality too. And by the way, it does make much more fun to work this way.

However, i find that the team should not be hierarchically organized. Every developer in the team should be equal (not the way our old Orwell meant it: "ALL ANIMALS ARE EQUAL, BUT SOME ANIMALS ARE MORE EQUAL THAN OTHERS." ;) we all know how the story ended up!). Of course there are seniors and more advanced members, but they will be forming the team, and other team members will respect them without any hierarchy.

The power of scrum is that it enforces the individual, and at the same time reinforces teams. It gives one the feeling of freedom. The developer is not a resource any more that can be assigned to one or another team, for 10% of a week and just do some job for the manager that got him from his boss. His performance can not even measured. The smallest unit is the TEAM! At least concerning controlling!

For the old fashioned manager, who manages his resources and got his weekly reports about the progress on this and that project, this seems to be a pretty inconvenient situation, if suddenly, that particular excel rubric can not be rewritten, or moved to another project, or even can not be evaluated/measured on its own.

Who cares, which developer had made it. It was the team! And may be one or another developer is not so good, but we all have our strengths and weaknesses. And you can be sure, if a team keeps somebody, than he/she's worth to be kept.

However, scrum does not mean the loss of control. If you look at it, it gives much more control for the management, since it delivers real value! It's not about working hours spent on this or that, it's just about functionality, you've got integrated into the project. It's about transparency, you got by the product backlog and by the story board. It's about risk mitigation you can get by the short iterations. The main problem with scrum is that it is different! It is not the old school, and chaps of the old school need some time to change (could ask Galileo he knows it well! ). I see pretty the same situation with scrum. You can prove it by doing. You should just start dong it! But the old school won't start with it, since we all know: the Earth is the center of the Universe.

Another big advantage of scrum comes with effort estimation. Planning is a hard stuff. As the old good Churchill said once: "It is difficult to make prediction, especially about the future".

So, what to do (the ultimate  recipe of planning):

1) Get an experienced developer, and let him/her be a leader or manager. You can be sure, that with the time she got away from the code.

2) Let him the one who is authorized to make effort estimation (give him a star ;) )

3) Discuss the requirements and wait for the magic number: 42

4) Ok. if you have a good project manager she would still multiply it by two! Just to be sure ;)

It sound so cool, since we know, the chap who made the prediction was a really good software developer... but forget it. It fails in most of the cases completely. The chap with the star will communicate less and less with the poor developers! He is better now. He is authorized! The effort estimation is his responsibility, so he doesn't need to consult with the developers! He might do it, but it won't be enough, and it gonna be even less and less. I'm pretty sure about it (unfortunately).

But wait, just call your team together for a game. Just meet a room for a day and play poker with them! The development team has the most adequate information to make a good effort estimation. If they are not influenced by some lead or boss or manager or whatsoever, and are supported by a qualified scrum master and product owner, the result of the planning will be impressive!

In my team we have made many mistakes, and did not apply the process the way scrum suggests, but still we achieved much better results on effort estimation by introducing user stories, and start using story points.

But again. You can call it ideal day, or story point, or potato, it doesn't matter what the unit of estimation is. The real matter is, how to get to the result! 

"The plan is nothing but planning is everything" 

development leads in scrum !?

Just assume that we decided to became agile and managing our development process in accordance to scrum. So we gonna have some product owner (PO), scrum master. Beside the development team we also have software architects involved in the product development.

The scrum master must help the team to improve, to be more affective. He tries to identify and to remove impediments, arguing with the PO, keeps the management off the team (if its necessary to do so), and so forth.

Anyway, I wondering whether we need an extra role have introduced to scrum: development lead.

Or may be the scrum master is a kind of development lead?

In the referred page its well defined that "The development lead is the mid-point in the path between being a developer and being the solutions architect." 

and further 

"The development lead is responsible for fleshing out any of the details in the architecture that the Software Architect didn't spell out in detail and for the creation of program specifications from which the developers work."

I thought, as naive as I am, that in a scrum team the team is mixed up, with some senior developers some newbies some field experts, and discuss intensive on User Stories during the planning and the development, under the instruction of the scrum master (who should/could(?) also help the team to understand the architectural aspects resp. constraints). On particular questions the architect(s) should be available. 

What is a development lead good for in such a process/ organization? May be we could just kick the scrum master and establish a development lead instead. Are we then still agile?

Further in the article: "The development lead spends a great deal of time managing the development process." But if we claim using scrum, is this not the role for a scrum master?

The last question for now: is it actually a matter how we label a particular role in the development team? Makes it our development process/SCRUM better or worse if we don't have scrum master(s), but development lead(s)?

Who cares!?

Kick off

Welcome stranger,

at this irrelevant, tiny point of the Internet's universe. At this place I'm going to start to jabber over my daily desperation in the maze of software development. I'm currently pottering with product development and have some years of experiment in this field.

At my company we are suffering under an over managed over controlled, vast and incalculable development process, with some sick project/organizational hierarchy, that merely blocks the chaps pretty much. At this point I might exaggerate a bit, however you can judge it for yourself by following my blog.

I'm really interested onSCRUM and agile development methods, and unfortunately I can tell a lot about how NOT to do it. :(

I hope that with stories of mine I can keep you away of doing the same mistake, and may be some of you can give some clue on how to make it right/better. ;)

On the other hand I'm gonna post some design considerations, and technical questions that are worth of thinking on. And of corse some anti-paterns, to see how we should write code if we would like to became a manager. :)

As you might already recognized, I'm not a native english speaker, however I think my literarily underdeveloped, or I could simply say BAD english will still suffice for this task.

So I'll cut this boring, useless piece of byte-flow now

cu