7 tips for managers to successfully un-manage
By Bachan Anand / Filed under Collaboration, Inspect & Adapt, Self Organization, WORK is GOOD / February 5th, 2012
It’s always amazing when a group of people pleasantly surprises and inspires us in the most unexpected ways. A couple of days ago, I was listening in on the weekly Review and Retrospective Meeting that the Conscires team conducts at the end of each Sprint (yes, we do practice what we stand for and promote!). My intention was to find a bunch of things that I could coach the team on (in this particular case, ‘coaching’ was a nicer way my mind looked at the evil intention of telling people how they can do better – in other words, how I could ‘fix’ them!)
Anyways, I was on this call while I was waiting for my flight and the team started with the review. I could hear one person talking about another’s task. I jotted down, “Why is Indu updating everyone on what someone else had done?” Right after that, she said, “I don’t know about this item and will need to wait for Deepa.” So Mr.Coach in me had to erase his comments, for Indu was only speaking on behalf of an absent member of the team. Soon, I could hear the others talking about their own tasks. Thank God I did not speak out of turn and state something to that effect in the meeting. As the meeting proceeded, I was amazed how self-organized, happy and collaborative this team is and, mind you, this is a distributed team – no one sits in the same room during this meeting (some of them are located on opposite sides of the globe), no one has met more than half of the team members; in fact, I doubt if anyone has actually met more than 6 people in the team. As I continued to listen, I was delighted at how much the team has achieved, and to see that they also take accountability for what they couldn’t finish.
The meeting, facilitated by Lisa, moved on from reviewing the work done in the previous sprint to retrospective, in which everyone spoke about how they felt regarding the way we were working. Even though I was about to board the flight, I wanted to listen in with the urge that hopefully there will be more coachable moments. The team started the retrospective with a “Perfection Game”, with each team member rating the sprint on a scale of 1 to 10, and capturing what could have made it a 10. It was encouraging to hear honest shares on how people felt and what they believe will get them to a number 10. It was so cool to see the team encouraging one of the members to move from a 9 to 10, as she couldn’t really come up with a reason as to why the sprint deserved only a 9!
Lisa then asked the team whether they wanted to do a “Start – Stop – Continue” activity or just do Shout-outs for each other and Jeena suggested Shout-outs. The “continual improvement” side of Mr.Coach wrote down, How do we improve if we don’t look at Start – Stop – Continue? Well, since the announcements were going on at the airport, I couldn’t seize what I thought was a coaching movement and come up with a question like “What action items would come out of this meeting?”
The team captured the shout-outs, applauding each other for doing a great job and acknowledging each person’s efforts in supporting others. It was amazing to feel the positive energy those conversations created. It reminded me of a discussion I had over lunch about how we lack positive feedback at workplaces and its negative impact, and also the dearth of feedback when things are going right.
I felt fortunate to see a team do so well, and was a little annoyed with myself that I would have spoiled those meaningful conversations with my coaching tips – thank God Southwest did a rather loud announcement for boarding!
Here are my takeaways from the meeting:
1. Be happy to be wrong: Keep your judgments away while you are coaching, be patient and observe what the team is up to.
2. Meaningful conversation vrs action items: What we need in workplaces is a safe environment for more meaningful conversations, instead of action-oriented meeting minutes.
3. Learn from your team: Remind yourself that learning comes from unexpected quarters, be open to learning when others expect you to teach.
4. “Management by leaving the room” is important, especially when you feel responsible for running a company or managing a team.
5. Re-invent your job as a manager: It is not that managers are evil, we sometimes put ourselves in such situations. The only solution I see is to have everyone take responsibility and manage, so essentially Quit your job as a manager.
6. Accept the greatness of the team. The team would do quite well just the way they are, without requiring anyone to fix things for them. They just need opportunities to communicate and share.
7. Love your team members: I know Lisa really meant it when she told me the other day “Everyone loves Indu,” it was evident from the Retro meeting. I would even take it further to say, everyone in the team loves each other, or am I taking that too far – ?
And yeah… we don’t always have to do START – STOP and CONTINUE to be on a path of growth, just do Shout-outs and bring on that Positive Energy!
How Agile & Scrum contribute to Team Morale
By Bachan Anand / Filed under Agile, Collaboration, Inspect & Adapt, Scrum, Self Organization, WORK is GOOD / September 28th, 2011
How has using Scrum and Agile as framework helped team work and morale of team members?
We asked this queston to other Agilists on Linkedin.com, and received some profound views and interesting perspectives. We think the readers of our blog could benefit from these insights.
Here are the extracts from the discussion.
1. Nothing helps morale and teamwork like success.
2. The Agile framework has unknown details that keep the team excited about the challenges ahead. The scrum meetings, prioritization and changes add a lot of dynamics to the discussions and keep the progress live and happening. Quick iterations of requirement-development- review-closure cycle and client involvement in each of them keep the adrenalin flow high all through.
3. Project Management team has no option but to share all the contract details of the project, so the team is bound to be highly motivated and involved both individually and as a team.
4. Agile approaches treat each team member with respect. This can be a really big positive change and has a wonderful effect on morale.
5. Some team members view the Agile approach with trepidation; there’s no longer a place to hide. Without the ‘respect’ aspect, that ‘nowhere to hide‘ can be disastrous to the team morale.
6. If things get done right, the effect is very positive. But it can all go bad for the want of a bit of real knowledge about Agile approaches.
7. The autonomy given to the team becomes a significant and ongoing reward for their efforts. Autonomy is something only more senior positions offer in many situations; having such choices and freedom is a major enhancement of morale, if the team members have the courage to use it.
8. Communication!
- Increased alignment and communication between customer and team members
- Transition in role of PM to running interference and reduction in unnecessary artifacts should increase productivity
- Daily information exchange between key players should cut down on expectation gaps and result in timely issue resolution or escalation
- Focus on objective/quantitative progress & velocity reporting metrics should create a “level-playing field”
- Retrospectives & regular refactoring of methods should translate into better productivity and less firefighting
9. Collaboration!
- The team is self-organizing! This help the morale.
- The team can see results quickly and have feedback from customers: that’s also a great benefit for developers
- Testers and developers work together, which usually, at least long term, reduces bugs and helps to spot problems earlier, which makes problems less painful to solve and reduces their impact.
- The full team delivers together, which increases team building and collaboration, and usually people are ready to help each other and share their knowledge.
- Finally, if scrum is well implemented, it allows to reduce the number of meetings (especially the useless ones).
10. The customer is engaged continually in what is being produced, which means that there are no surprises in that regard.
Can you add to this list, from your own experiences?
Contributions by Owen Jay Murphy, Praveen Kumar Kambhampati, Paul Oldfield, Gareth Blake-Coggins, Bernard Kahn, Kiron Bondale, Lorenzo Granai, Chris Browne. You can read the entire discussion here.
Sprint Review – Your time to shine!
By Bachan Anand / Filed under Agile, Inspect & Adapt, WORK is GOOD / August 24th, 2011
Agile constantly advocates transparency in the entire product development cycle. If the customer can see the product under development at every stage, it gives him confidence. Demonstrating their efforts to others boosts the morale of the team.
Rather than wait for the final product, the stakeholders would be eager to see each functionality as it develops.
The Sprint review is a meeting to show the working functionality that was achieved in each sprint. This meeting happens at the end of every sprint.
The team, the Product Owner, customers and other stakeholders gather together for the demo. The team demonstrate potentially releasable portion of the project corresponding to the product backlog items completed in the current sprint.
The Sprint review is an informal meeting that requires no preparation other than getting the relevant part of the software to work.
The outcome of the sprint review:
The sprint review throws light on how much of the requirements have been completed, and whether the team was able to translate the requirements to working features as expected.
Discussions that follow provide feedback from the stakeholders on the desired changes to the functionality, and the priority of each change. This would set the premise and pace for the next sprint.
The sprint review is an opportunity for self-organizing teams to constantly astonish their customers with what was created and also to provide transparency on what was not.
It is an opportunity for the team to showcase their efforts and build faith in each other.
It is the time for the team to shine!
Keep your Agile Retrospectives fresh and lively!
By Bachan Anand / Filed under Agile, Inspect & Adapt, Scrum / June 20th, 2011
As Agile enthusiasts never tire of emphasizing – and rightly so! – Agile Retrospectives help teams inspect and adapt, and lead to continual improvement. However, for all their importance, Retrospectives run the risk of becoming repetitive and boring, especially when (in the case of weekly sprints) they are conducted week after week. The effectiveness and purpose of the whole exercise are defeated as time passes, and Retrospectives become merely a routine to get over with.
Here we discuss ideas from different people on how to make Retrospectives interesting, lively and something to look forward to.
Esther Derby explores seven ways to revitalize your sprint retrospectives and also explores the factors that contribute to the failure of retrospectives.
Mark Levison offers views on the question often asked by Agile newbies: How are Retrospectives different from post-mortems?
Nathan Jamin examines the challenges faced with distributed teams, and shares a few thoughts on how to solve them.
Feedback is essential for continuous improvement. But what you don’t want is the kind of feedback that causes someone to withdraw from the loop in order to stop the feedback.
Keeping retrospective discussions interesting, collaborative, constructive and energizing is no easy task especially when running weekly retrospectives. Here is a method using Lego ® serious play to facilitate the gathering of data from the last iteration.
Communication is very often the stumbling block in discussions. Once a person has spoken in a meeting, he is more likely to speak again, says Nick Oostvogels, in A Retrospective Check-in Exercise.
Nick also stresses the importance of visualizing the emotions of the team throughout the project and recommends an exercise based on the children’s TV show, Mr Squiggle, to take temperature of the team’s feelings about the state of the project. Nick shares 12 retrospective exercises to ensure the retrospective doesn’t get to be a boring meeting. Brainwriting is a technique you can use to avoid continuously looping around the same discussions.
The Rising Patton Fusion combines the techniques of Linda Rising and Jeff Patton for an interesting retrospective.
Your turn:
What are the methods you employ to keep the repetitiveness out of Agile Retrospectives and to make them engaging and lively?
How Agile Projects Can Fail
By Bachan Anand / Filed under Agile, Collaboration, Inspect & Adapt, Self Organization / April 23rd, 2011
Many companies who decide to go the Agile route assume it’s their salvation for cutting time and costs on a project. That’s not always the case.
The fact that members of your leadership have agreed to switch to Agile doesn’t mean the team will be on board right away. People despise change, and often resent a third party coming in to completely turn around their systems and processes, even if it is allegedly for the best. It can be an uphill battle, and a time-consuming one.
Understand the common obstacles to ensure your team works to circumvent them:
-
Management is not actively promoting the benefits of Agile.
-
There is no Agile Champion helping the buy-in to Agile.
-
Leadership expects the conversion to happen quicker than is realistic.
-
The team members are not owning what they do.
-
Team members do not have a sense of urgency to make the change.
Leadership’s Role
Certainly, the person who signs the check may have influence into whether a team turns to Agile solutions, but his role doesn’t end there. It is key to have management on board, fully understanding the implications and benefits of Agile, and to cheerlead the team regularly. People follow by example.
Identifying an Agile Champion
Finding someone who fully supports the move to Agile can help the team with the transition. An Agile Champion should be someone enthusiastic about Agile who can talk to people about how it will help the project and the team. This person may field concerns and complaints and help to identify whether they are simply a resistance to change or whether there are more serious implications that need to be dealt with before moving forward. The Champion should be internal to the team; not the third party coach or consultant.
Giving it Time
Agile coaches or consultants must stress up front a realistic timeline to get a team up and functioning in Agile. If the team is on board, it may happen quickly; if not, the time and space needed to convert will stretch out. Leadership must understand that this is not an overnight process, and must support the effort throughout.
Own Your Own
In Agile, each team member has a specific role, and is responsible for a specific set of results. It is key that this team run like a well-oiled machine. Team members must own what they are responsible for.
Getting Urgent
Usually a company decides to implement Agile because of something that’s broken. Leadership wants to stop the problem and set up better processes, and they see Agile as the solution. But if all the team doesn’t feel a sense of urgency to make the transition and stop this problem from continuing, the shift to Agile will be slower and more arduous than it has to be.
Agile works, but not for every team. Without openness to change, a conversion to Agile will be futile.
