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.
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.
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?
My site is at http://toolsforagile.com.
I blog at http://toolsforagile.com/blog/ ,
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)