In my previous post, I talked about what can Scrum do for Developers (team members). Today, lets talk about Managers. I’m taking about delivery managers, project/product managers etc. Generally, people who manage people who make software.

Managers crave for Commitment. They would like their people to actively make commitments and work on them. In Scrum, the team makes a commitment each sprint. Everyone in the team strives for this common goal. They self-organize, kill impediments and generally do whatever it takes to meet the commitment. Usually, after the initial few sprints, the teams will start meeting their sprint objectives fairly regularly. Team members prod and inspire each other throughout the sprint to keep everyone moving towards the goal. The manager can just sit back, relax and watch! (a fairy-tale, isn’t it?). Well, not really, a manager will be called into action to resolve some impediments and problems that are out of team’s hands. Scrum teams are better positioned and equipped to manage their commitments, taking at least some load off the managers shoulder. So, rejoice!

But the manager’s boss will hold him accountable for getting things done (or blame him otherwise). Generally, managers don’t really work on making software, they rely on other people. Which may make them feel out of control, and they may start micro-managing the team or bothering them every few hours for updates! (“to stay on top of things”). Scrum addresses a lot of these issues. First of, the manager gets better predictability based on team’s velocity. It gives a fairly good indication of how much the team can do in future sprints. And with with daily scrum, sprint BurnDown, sprint review and release BurnUp, you can stay on top of things without having to ask for it.

I’ve saved the best one for last: Teamwork. If you do Scrum right, your team will work like the Avengers! Well, almost. The common sprint goal gives the team members a sense of purpose. They will set aside their differences. They will figure out who’s best suited for what, how to bring everyone to that level; they will coach each other, critic each other and support each other. They will work with each others’ strengths, and work around (and eventually improve) the weaknesses. Just like the Avengers! (you see?!)

We had a hierarchical structure with my previous employer. The project manager, apart from taking care of project related activities, was also responsible to oversee people issues. These conversations used to start with “Can I talk to you?”

People issues such as someone is not getting well with the team, consistently not present for some key meetings, not spending required number of hours in office or not being productive during work hours or staying late consistently or not effective at work and so on and so forth.

So, in Scrum world, how do we deal with people problems? Who is responsible to help the individual? Simple answer is “The team”. It’s easier said than done. At times, it’s difficult to have these conversations; especially if not all team members are matured.

This is when team should make some agreements with each other very explicitly. Create a structure within the team where they can give and share their inputs openly and accept feedback with an open mind.

This is what I propose for it.

1. Team should define what is important to them. It can be values such as

• Client Success
• Punctual
• Committed
• Focus only on work during core work hours
• Proactive

2. Identify the agreeable way to give and ask for ad-hoc feedback on these values
3. Define a structure where each team member is evaluated by rest of the team.
4. Identify how someone can get help or lend help to others.

New Year is round the corner. It is that time of the year where all of us setout goals, make resolutions, define plans to achieve them. I believe setting goals is important as it acts as a guiding post on how our energy, time and efforts are going to put in.

Let me share a simple but great thought I picked up from a speaker in one of the conferences I attended recently. We are always ambitions. We always focus on the things that we are yet to achieve, fix things that have gone bad, try to find and fill the gaps. In a nutshell, looking glass half empty. I don’t mean glass half empty in a negative way. It is important and required to see glass half empty so we set goals to become better at we do, how we do, both professional and personal level. At the same time, it’s important to look at glass half full.

Look back at the year and ask, “What has improved”, “What has changed”, “What I/we did exciting this year”?

I recommend to do this “Yearly Review” with your clients, family and yourself.

We all take success for granted and, forget it and focus on new challenges. Before we set out goals, acknowledge success. See glass half full before figuring out how to fill the other half.

What is a Sprint Review/Demo Meeting ?

- highly productive feedback loop that enhances your Scrum Team

- It makes the progress of the team transparent ( to management, stakeholders, to other teams and themselves)

- A chance to show what they have achieved and a forum to celebrate their accomplishments

- Tick of things which are done.

Why should the Sprint Demo be awesome??

- Touch Point with your customer – They remember this and most of the time determine how things are based on this interaction and the results of this discussion.

- Moreover, this is what the team worked hard for a complete sprint to achieve, this is “The Moment” to showcase your efforts and get feedback and improve on the product at hand.

Does/Dont’s for Sprint Demo :

- More than just a demo

- Ensure that you have invited the right stakeholders (involving the PO)

- There should be an agenda – Demo Script

- Demo Setup – Up and Running ( As agreed, consistent. Not demo apart from the demo environment)

- Environment – Bright lit and not boring and dark

- Energy is very important, the person giving the demo should be aware that he is demonstrating every body’s work in the team, the energy should reflect in the demo.

- Interesting and a bit informal ( depending on audience)

- Ensure that it is visible to all in the meeting

- Do it from a single machine/location.

- Be available ( not someone walking in after the demo starts).

- Keep your mobiles (silent),other sources of disturbances at bay

- Prepare for this Interaction (it should be “Great”) and “No surprises” – Pre-demo. Create Relevant test data, if the story has no visible UI provide relevant tests. Don’t skip them.

- Time Box it 1-2 hour for a team of 4-5 professionals ( 2 Week Sprint)

- Have an introduction from the Product Owner on the Sprint Goals – on what to expect for the stakeholders

- Inform everyone: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?

- Use your best communicators for the sprint demos.

- Welcome all feedback, make a note of the same ( any team member) and sent it back to the PO and stakeholders

- In presenting every story provide a business overview of the importance and a bit of background of each story = What Business Value it has, what problem is it solving, benefits and so on.

- Focus on the acceptance criterions of the Story – avoid exhaustive repetitions of scenarios and keep it interesting and what’s valuable.

- Not Done items are not demoed.

- Never cancel a demo. If the team has nothing to demo, then display the progress at the demo- but never cancel it. Cancel the demo sets a bad signal to the team that the demo’s are not important.

- Ask for suggestions/feedback on gaining more business value.

- Decide with the PO on how to work on the feedbacks and priority.

- PBI’s are not marked as “Done” before the Sprint Review

- The DoD contains the Quality Metrics (Code Metrics), Testability Parameters(Unit Tests and Functional Tests Report) and Practices(@Prowareness we use a 30 Agile Practices list and only showcase the ones which were really DONE) used – show them, no proof only adds to the customer imagination. Transparency does wonders to build trust with stakeholders and management. Incase your customer is non technical ( have no clue about quality, educate him about him – after all he may have to spend effort/money in managing the solution later on, its his right to know what quality did he sign up for)

- Always celebrate (cheer/champagne/or just a thank you) at the end of the demo with all the team members and other involved in making the sprint a success.

Looking for the right recipe for your team demo, try the following out ?

>>Create cross functional team/group of 4-5 people

>>How would you rate(1-5) the last demo you attended ?

>>What was the best demo you ever attended and what was special about the same ?

>> Create the perfect Demo recipe (share and discuss ideas across teams)

- Audience

- Setup( Infrastructure and Environment)

- Preparation

- Execution of the Demo

- Closure

One of the biggest challenges for agile teams or for that matter lot of organizations is fear of conflict. This fear of conflict is a major reason why organizations fail to call right shots. In a survey conducted among US and Europe executives, 85% have acknowledged that they had issues/concerns at work that they were afraid to raise. They were afraid of conflict that would provoke, afraid that it would lead to arguments that they won’t know how to manage and loose.

Arguments are necessary; disagreements are required to drive creative solutions to problems. Well, easier said than done. How can we have these conversations more easily and more often? Organizations culture should reflect and encourage the attitude of questing, willingness to start an argument. Imagine in an agile team, if individuals are hesitant to prove others wrong, it will ultimately do bad to the team.

Developing “Prove me wrong” attitude doesn’t mean that team/organization loses team sprint. In fact, the opposite would happen; there is even more team collaboration, very little room for wrong decisions or judgments. The reason why Phd theses have such a high quality is because they have to pass “Prove me wrong” phase.

It is not enough to make things transparent and open, but as I mentioned above, the discussions and arguments around it is what makes it effective.

Openness isn’t the end; it’s the beginning.

Credit: This blog is inspired by the TED talk give by Margaret Heffernan – Dare to disagree

Back in collage days, I learnt a lesson when my friend almost killed me (not literally though ) when I responded to a question by saying “yes, you look fat”.  Recently I noticed such a scenario in a team, well it’s nothing to do being fat but fundamentally it was same, “Giving and taking feedback”.

I believe that feedback is a gift. It always helps us grow personally and professionally. Yet, most of us have a negative perception towards it. Most of us still believe age old saying “If you don’t have anything nice to say, don’t say anything at all.”

Today’s demanding and challenging work environment calls for an imbibed culture of giving and receiving feedback. This aspect should be even more emphasized in agile teams. For example, lot of agile practices have an inbuilt framework to facilitate faster feedback such as with XP, we have CI, Pair programming, Peer reviews etc, with scrum we have retrospectives etc. Most of these feedback mechanisms are targeted at technical accepts and abstracted at team level.

In order to have hyper-productive teams, individuals should be comfortable to give feedback at an individual contribution level to acknowledge his/her achievements or to identify any growth areas.

Here are some points on giving and receiving feedback.

1. Give your feedback as soon as possible: If you notice something done really well, don’t wait till a retrospective or some event to give a pat on back. If it is appropriate, drop an email, or post it in a bulletin board about the good work. At the same time, if you see something can be improved, or done at substandard level, let the person know ASAP.
2. Balance your feedback: Always start your feedbacks with a positive note. It is important to mix both positives and growth areas.
3. Be Constructive: The whole idea of giving feedback to help the other person to grow and not to criticize. So, always give your feedback in a constructive way. Be careful with the language you use. Replace words such as “but” and “however” with the word “and” when you string together your positive and negative feedback. When people hear the word “but” they immediately discount the part that came before it and only hear the negative comments.
4. Listen: While receiving feedback, listen to the other person’s point of view. Perceptions are true at least for the ones who own it. So here it out without any justification or explanation.
5. Reaction: If you don’t completely accept the feedback, thank the person and tell him how you are going to take that feedback. Be careful, it sometime do happen, that rather than accepting the feedback, we tend to denounce not only what is said but also those who say it.

Always remember, if someone is giving you feedback, it means they are interested in what you are doing and wants to help you to become better at it. Now, coming back to my collage days, if I had known point 3, I would have said “This dress suites you very well and I guess you look little big now” (not sure if it would have really helped)

Naturally, I’m tempted to answer “YES” to this question as I wear my Agile Coach hat at work. As I pay close attention to the person’s conversation, what he/she is really saying (screaming inside) is bunch of fears such as

• Fear of failure
• Fear of change
• Fear of moving out of comfort zone
• Fear of learning curve
• Fear of wrong decision
• Fear of transparency
• Fear of losing control
• And it’s so easy to give orders or follow orders J

So, when you want to convince your boss or your customer to go Agile, ask what challenges they think that exists currently with their organization or team. It’s much easier to focus on solutions and start that conversation when people acknowledge that a problem exists.