Time boxing work – the nano sprint

The best way to experience the power of time boxing is to do sprints of 1 hour duration using a timer. The count down starts from 60, 59,58…and the pressure to complete the task planned within the one hour start building up. The pressure with pleasure. My ipod which I abandoned long time ago have found new purpose now as my timer. At the end of the day, it is not that great news. I have not done much of that useful, important work. I will improve.



A young gentleman walks into my cabin for…

A young gentleman walks into my cabin for the first time to borrow some money for his lunch, and he is a team member who did not get his salary on time. That was a very powerful message to me. Points to the challenges of a start up, and the sacrifices and sufferings behind a startup. Unfortunately it is hampering the commitment and motivational aspects of the team, which dilutes the sprint.

Story tellers….

What is the story of your project?. What is the story of your work?. What are the stories of the users of your product?…How is the product going to change / make their stories inspiring. Can you narrate it with enthusiasm?. Only then you should write the user’s stories…else they become dull and pale…and will not deliver much value to the users. Today was a forced holiday, due to bundh (strike), and that gave me some time to introspect about my current project. Unfortunately, I am struggling to narrate the story of my project to myself convincingly. Do you have a project story for me, which can be narrated to me with enthusiasm and passion…

Writing a story is different from telling a story. If you have to tell a story to an audience and capture their attention, then it must have something in it. We can always write boring stories and send to someone, where as we cannot tell an uninspiring story successfully.

Liked this video about UI design

Reusability is a mindset

That is the learning of the day. After a long stint of coaching, today I had the opportunity to listen to a very experienced person about various aspects of software engineering. One of his catch phrase was ‘Reusability is a mindset’. That answered my dilemma of defining the reusable components. Should it be a module, a function, a template, error messages, test cases…it could be all of these and more. That is my learning for the day.



When the sprint fails…

Whenever I discuss about the need for ‘committed’ , ‘capable’, ‘motivated’, mutually respected teams as a pre-requisite for scrum, generally the body language of the recipient of this is that of cynicism. Unfortunately, in reality, based on my experience , agile frameworks, or any ‘knowledge related work’ is bound to fail without these basic human elements. Of these ‘mutual respect’ is the most important aspect. Without mutual respect, commitment will not happen. Without mutual respect, motivation will be affected. Everything starts from mutual respect, between team members, scrum master, product owner and the sponsor. The litmus test of ‘mutual respect’ is how gracefully we treat an agile team, during the sprint review meeting of a failing sprint.

Planned velocity is ’10’, achieved is ‘6’. If ‘6’ is not agreed upon by the product owner, then the sprint has failed. Will this lead to ‘release date’ slippage. That could be the immediate concern of the product owner. Answer is a ‘yes’ and ‘no’. This may affect the release date. This may not affect the release date if the velocity increases during the subsequent sprints. The most important aspect to be taken care of during these scenarios is to protect the ‘motivational’ aspect of the product owner, scrum master and the product owner. When the team is in the forming state, and working on a new technology / architecture, this is bound to happen. Patience is the key to deal with such situations. This is the time to invest heavily in production capability improvement, than hitting the roof for low productivity. Remember, great managers do not do much to motivate their teams, and at the same time, they do not demotivate their teams. One must protect the commitment, motivation and mutual respect, self respect aspects of self organizing knowledge workers throughout the assignment at any cost. This is applicable to all stakeholders including the development team members.

Recently we had a long project team meeting to resolve an issue. We invited some key team members for a critical meeting to get out of this do or die situation. They participated actively, we planned all the action items to be implemented the next day, and towards the fag end of the meeting the one key team member who was also part of the entire meeting turned up and said ‘I am on leave tomorrow‘, while waiting for the cab to go home at 10 pm. That really hurt, and still hurts me, the senior manager, who pitched in to help, even when it was not my key responsibility. I am not against someone taking leave for genuine reasons during the middle of the sprint. He could have told me about  leave upfront, which would have given me opportunities to plan other alternatives.  I am also human. Yes, respect has to me mutual. In agile teams, we motivate each other. The entire team must commit to the sprint goal and achieve it.


A word of caution about Transparency and predictability

Yes, I stick to the promise of scrum delivering better predictability and transparency. The flip side of this is what we see through the newly gained transparency. The reality could be bad news. Just by following scrum alone the productivity will not improve. This realization happened during the consulting assignment at a startup. I knew that engineering capabilities will not happen overnight in any organization where everything was happening ad-hoc,  which is the characteristic of almost every startup. They needed holistic approach to improve;

  • pre-sales process
  • project planning
  • project tracking
  • requirements management
  • design / architecture
  • estimation
  • coding
  • testing
  • defect management

I did not want to reinvent another capability maturity model, because i felt it will be better if my client implement something proven and popular. That forced me to go back to the CMM-Dev model after two decades. That is a great opportunity to look at CMM-Dev from an agile perspective (not from the CMM assessment perspective. Here are the KPAs of the CMM-Dev latest ;

  • Causal analysis and resolution
  • Configuration management
  • Decision analysis and resolution
  • Integrated project management
  • Measurement and analysis
  • Organizational process definition
  • Organizational process focus
  • Organizational performance management
  • Organizational performance management
  • Organizational training
  • Product integration
  • Project monitoring and control
  • Project planning
  • Process and product quality assurance
  • Quantitative project management
  • Requirements definition
  • Risk management
  • Supplier agreement management
  • Technical solution
  • Validation
  • Verification

This is in alphabetic order. To my surprise, the current level is almost 0 for most of these and 1 for some of them. I consider this as a good starting point. Still we believe in people more than processes and tools. We will ensure that nothing that does not add value will get rolled out.