Hello and Welcome

I'm an ex-Project Manager who currently moved on to Agile Consulting and this blog is my sounding board. This blog was started in 2008 journal-ling through my project management journey, today it combines both- my passion for all things project management as well as looking into the agile way of transformation and undergoing changes.

Here I write about my experiences, struggles, failures and joys. I also interview, do book reviews and keep you updated.

I usually post twice a week: Monday and Thursday unless I am too caught up which is often these days

If I'm not working; I can be found reading up on project management, agile, coaching or business books with a cup of green tea. I love to read, push the envelope one step further, work on new ideas, experiment, travel and explore life.

You can reach me at steppingintopm@gmail.com

Will Power and free resources for wannabe Project Managers

You never know where inspiration comes from
.
I have been doing random stuff to keep myself going and one of it has been watching youtube videos. I recently watched a TED talk by Kelly Mcgonigal and that led to watching more talks by her. This one is my favorite.
It talk about Will power and what we can do to attain it and how smaller interventions actually change the way we think.


I also read up her “how I work” series in LIfehacker  as it seems very natural to see how she does it in real life. I hope this video gives you the will power you need to pick up or face a storm in your own work space or life .

 By the way if you haven’t noticed, there’s a new e-book in town by Geoff Crane where he has gotten 52 project managers from all over the world talk about their initial experience into the work life and profession. Its insightful and a must read for all including seasoned players- there’s something in it for everybody. And am more than honored to be part of his project. 

Guilty as charged

I multitask and can do it well. Really well.

I put hours at work, I blog, I write, meet lovely friends, keep in touch with everybody and barely give anyone the chance to complaint.


The last few months, I have stopped multitasking. Not really deliberately, it just happened. Work was crazy and by the time I was home I didn't feel like doing hundred more things. I wanted time for myself, sometimes doing nothing.

And I felt guilty, especially about not being able to meet friends or writing my blog like I used to do. I wanted to be away from my laptop. I even stopped browsing. I stepped away.

I probably haven been writing but every day I am full of guilt that I haven’t been doing what I should have. I see other bloggers or professionals who are doing well, so inspired, so full of energy and I still don’t feel like writing.

It could be writers block, it could be doing the same thing for so many years now or it can be just wanting some time for myself.

Today, I browsed through some articles and wanted to know if there are more people like me who feel the same. Or am I just losing my fire?  

I read about mothers feeling guilt , about difference in the way men and women approach work  and multitude of other stuff.

Bottom-line, yes we should be responsible in what we do but I just feel sometimes it’s okay to do random stuff out of the daily routine. It’s okay to want some time for yourself to get recharged and then be back or choose not to be. Enough of guilt!

So yes I have been spending some time doing nothing except regular work. And to my all my readers if you have expected articles and seen the same one and no new updates over and over again- I was busy in my balcony looking at the mango tree and sky and birds. I was spending more time with myself than with anything else, definitely not my laptop.  

Have you been through same situations may be in different context?


I am hoping I will be writing very soon, but bear with me if it takes time- blogging is tough.  Meanwhile enjoy your schedule and what you are happy doing and if you are not- take a break minus the guilt.  It will certainly help!

(Pic Courtesy: Soma)

Scrum Team has stabilized- what next?

Most transformations start with the basic idea of either getting teams to start working in Agile or streamlining their existence process.

At a certain point, teams stabilize, velocity improves, quality soars and things look up.

Is the goal to repeat the same cycle day after day or is there more to work through once the team stabilizes? I have always though that the trying to get teams working in Agile is more like a bicycle- if you stop pedaling, it stops.

Here are 5 things to consider as next steps to keep the team going:
  • Baseline velocity- Always know your baseline velocity, when you started and ways you can work on it.
  • Focus factor- when the team stabilizes, it’s a good idea to know if the team has the right focus. Its velocity/work capacity. For more info read Jeff Sutherlands article here .  
  • Failure trends and patterns- The commitment made by the team always doesn't match the outcome. Looking into why stories fail and trying to identify a pattern might lead the team to understand the underlying problem. It could be user stories that require infrastructure, it can be kind of stories that haven’t been worked on, it can be a story requiring a new technology.  Once you have identified the pattern, it becomes quite easy to find a resolution.
  • Estimations- If in every sprint more than 20 percent of stories remain not done, along with other factors you might want to have a look at the way estimation is being done by the team. Some teams commit more by underestimating stories in trying to please the management and keeping to the team’s velocity. Of course by the end of the sprint teams fail to deliver. There are more managers and Product Owners who always push the team to commit more, so they have enough work on hand ever sprint fearing lesser work meaning team members might be free most of the time. Bottom-line, under estimating doesn’t help as much as over estimating doesn't.
  • Linking and tracking the layers- Stop looking only at team levels and start looking at the bigger picture, look into the your program and portfolio management and how it  is coming down to the team. Look into the quality of the user stories and how everything is affecting the team.
(Pic Courtesy: Google Images)

To learn about how to get into project management read my book Stepping into Project Management (Welcome to the #PMOT World). To connect with experienced Project Manager's from all over the world, get mentored or shadow for a day see the SIPM Community.

Interview with Siddharta Govindaraj

Today we interview Siddhartha Govindraj, who specializes in Lean/Agile processes for software development. He has also contributed in the book "Beyond Agile: Tales of Continuous Improvement" published by Modus Cooperandi Press, Feb 2013 and Published in the March 2011 issue of the Cutter IT Journal on "Use of Kanban in Distributed Offshore Environments". An occasional organizer of events as a part of Chennai Agile User Group and speaks in conferences in India and abroad.

He was nominated for the Brickell Key award in 2011, an award given by the Lean Software & Systems Consortium for recognizing achievements in the lean-agile industry and is also a Fellow of the Lean Systems Society.

He is very interested in the behavior of decentralized and distributed systems.

Agile becoming mainstream now, how do you think the world of project management has changed?

In one way, yes….. definitely more and more organizations are seeing the value of agile in terms of incremental development and faster time to market. However, there are a few aspects where agile is still to make a significant mark. First, the people aspect of agile has still not fully permeated into the culture of many organizations. The idea that motivated, self-organized teams can deliver better software is not yet in the mainstream. I also think that many companies need to invest in the technical environment. The third aspect that companies often neglect is looking at delivery as an end to end system in the organization. Agile is often applied at the team level, and systemic impediments are not fixed. So there is still a long way to go. 

While older companies have a tough time with transformation, the good news is that newer companies like Facebook have been agile right from the start. Over the next decade, success of these newer companies will establish the culture for the whole industry.

As someone who creates tools for Agile and Lean project environments, please tell us what according to you is the most important: the tool or the expertise of the project manager?

Of course the expertise of the people in the project is the primary criteria for success. Where tools will help is in aiding decision making so that people (both within the team, and management) have better insights to take better decisions. 

This questions also leads to an interesting difference between agile project management tools and traditional project management tools. In agile, a lot of decisions are taken by the self-organized teams. Hence the tools need to be able to support the needs of the team. If the team decides that the tool is an overhead or is not adding value to them, then it becomes worthless. By contrast, the primary need of traditional tools is targeted towards managers, who are the decision makers to micromanage the team. 

A big problem is when an agile tool is used in a traditional way – i.e. the team does not feel the value, but is forced to use it so that the managers can micromanage them. My personal opinion is that tools that encourage this behavior rarely lead to truly agile culture. 

Tell us why you decided to create your software and did you use agile way of managing it while n development?

The previous answer has some insight into why we launched our tool. We saw that many organizations implemented tools which support agile mechanics, but not the agile mindset. Such tools get deployed, teams hate to use them but are forced to do so because the management doesn't trust the team and wants to control exactly what is going on in the team. Well, guess what? The team only updates the tool rarely and the data is unreliable so it helps nobody. This does not help build an agile culture. 

What we wanted to do was to build a tool that a team will find easy to use and useful for their own self organization. Basically, we took traditional, proven methods that teams use in a physical space -- card walls, task boards, story maps and so on, and made them available in an electronic format. This gives the benefit of electronic tools, while still being in a format that teams find useful for themselves. 

What according to you are the 3 qualities that every Agile Project Manager should have?

First, curiosity to keep learning. Secondly, soft skills to connect with people (within the team and outside) and build relationships. Finally, the ability to influence people and drive change and improvement. 

I haven't said anything about knowledge of agile. This is easy to learn, and anyone can learn what a product backlog is and how a particular process works. But the qualities above are difficult to train, and very crucial for agile success.

If someone new, stepping into Agile Project Management asked you about the 3 books to read, what would you recommend?
My favourite three books are:

1. Agile Software Development -- Alistair Cockburn (Quick note: This book isn’t about agile, but methodologies in general. It’s a great background about how and why agile works, but perhaps not what you are looking for if you want to know specific mechanics like how to story point a story)
2. The principles of product development flow -- Donald Reinertsen 
3. Kanban -- David Anderson

Where can someone find the link to your software and your books?
I've also been a contributor to this book - http://amzn.to/beyond_agile


Thank you very much for your time.

Does Agile mean NO Managers?

In trying to move in the right direction Agile-wise too soon, there are organizations who will consider removing managers or team leads completely from the equation.

However, removing the title doesn't mean, the role or the job has been removed and these management positions are simply disguised via different names. There are scrum masters sometimes who are actually functional managers for the team.


I think the reason these roles overlap is because sometimes organizations don’t realizes the role of a scum master.

A scrum master is the facilitator for the team and does not make decisions for the team. I think this is the trickiest factor that no management realizes. Scrum master isn’t the decision maker or someone who will appoint stories or tasks to the team. So a manager cannot disguise himself into this role.

So, one way to resolve this problem is to never merge both of these roles. Scrum master and the functional manager shouldn't be the same person. Even by overlapping roles for one team, you send out the wrong message to the other teams.  

The managers can happily co-exist with the agile teams and they can be great blocker resolvers. They should be the one helping teams deliver more by removing all impediments, looking into the patterns and trend of all teams and see what can be done to minimize the recurring causes of the issues.  


If management interferes and spoon feeds teams in every chance they get, teams never come close enough to becoming self-organizing teams and making their own decisions. Management can choose to either make teams adopt Agile better or make decisions that messes it u for the organization. 

(pic courtesy: google images)