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)

How should teams be build?

When an actor comes to me and wants to discuss his character, I say, “It’s in the script.” If he says, “But what’s my motivation?” I say, “Your salary.”

                                                 —Alfred Hitchcock, filmmaker (1899–1980)

Jim Collins talks about getting the right people in the bus in his book “Good to Great”. And we all agree- but how do you decide who are the right people?

Hiring happens based on the core competency, but when you put them as part of the team, how do you know they will work out?

Does team dynamics matter to you or your organization? Do you think it changes the quality of delivery?

The common failings for any team at organization level usually comes down to:

·       Develop empowered people working together to serve the best interests of the organization, and

·       Create an environment in which every employee contributes all of their talents and skills to the success of organizational goals.

To ensure we get individual players be and feel part of the team- is there a way to create teams at the first place differently? Like do you think, if teams are created based on their compatibility or interest, they will perform better OR do you feel any team if mentored and trained in team/organization culture will perform at their highest level?

To think about creating the right team, I think we should first think why teams fail at the first place? Why do teams not perform the way they should be? Is it a bad apple? Is it lack of proper management and setting the expectations? Is it freedom without no boundaries and when things go wrong, blame the team? Here are 20 mistakes that employers make.

Are we aligning people with their interest and what they want to do or do we just not hear what they have to say and push them into any role and any teams?

The hedgehog concept talks about looking into 3 aspects before putting the right people in the right role

By considering:

• What are you passionate about?
• What can you best in the world at?
• What drives your economic engine?

This definitely brings out the best in individuals but how do we ensure the best is brought out at team levels also?  What if you got the right person in the right role and then had a bunch of laggards as team mates. Do you think we have set the right environment for him/her to grow and contribute to the best of ability?

How does your organization formulate teams? What do you fee is the right way to do it? 

(Pic Courtesy: Google Images)

Interview with Ellen Grove

We are happy to have he opportunity to interview Ellen Grove, who helps teams do better work by coaching them to create the circumstances in which they can work most productively. Her Agile coaching practice with agilepartnership.com is founded in over 15 years’ experience leading software development and implementation teams in global enterprise, a passion for exploratory software testing and user-centered design, and a background in community organization. Ellen presents frequently at Agile conferences, most recently: San Francisco Agile 2012,Agile Day NYC 2012, Agile Tour Montreal & Ottawa 2012, Play4Agile2013 (Germany) and Agile Games 2013 (Boston).  She is the Scaling Agile Adoption theme chair for Agile India 2014. 

How did you begin in agile coaching/consulting?

I got my start as an agile coach while I worked for a large telecom company. My background is as a software tester, though I've done a little bit of everything except coding along the way.  My team had begun as a startup, which had been acquired by the large company but maintained the startup mentality of doing it all ourselves and trying to get things done with a minimum of process.  The company decided that they needed to introduce a standardized process for software development across the entire company; my team looked at the proposed process and realized we'd need to double the size of the team and the length of our release cycles just to handle the process overhead, which was obviously not acceptable.  

We decided that we would need to counter-propose an approach that would demonstrate some discipline in the process yet give us the flexibility we needed to do things very quickly.  Until then, we'd been playing with some Agile ideas informally, but hadn't really made an effort to work intentionally in an Agile way.  

This is when we got serious about Agile.  After arranging for myself, my boss and his boss to attend Scrum training,  I helped to organize and deliver Agile training for all the teams involved on the project: there were three teams involved, spread over 3 countries and a 10-hour time difference, as well as an external vendor who was supplying a vital component.  We were working in 1 week iterations (integrating the work of 4 teams) and learning a lot as we went along. I was playing many roles - leading the testing function, acting as Scrum Master for one team, and serving as an internal Agile coach to the larger project team.  I was also involved with the company's process team establishing an Agile alternative to the big universal process they were trying to introduce. It was crazy, but quite a lot of fun while it lasted.

When that role ended, my next gig was as a project lead on a non-Agile global network transformation project, very complicated and complex and risk.  What I learned from that experience was that I really only wanted to work on Agile projects, since Agile approaches offer some of the simplest ways to manage risk and complexity.

In a small company with less then 200 people following Agile, do you think a project managers role is as important and would be beneficial. Why?

Interestingly, in the large telecom situation there was never much attention paid to project managers, even though we had one on our team all along (even when we were still operating as a startup).  The PM was the person who updated Gantt charts, counted things and went to boring meetings that none of the rest of us were interested in.  It was quite a surprise for me to start consulting in other organizations where the Project Manager was effectively the leader of the project.

I think that many of the functions of project management are critical, but on a smaller team/project the important elements of the function can be built into the team's work and there's often no need for a designated project manager. Where I've seen real value in a PM role is in larger organizations where the PM acts as an interface (and shield!) between the development team and other functions in the company, allowing the Scrum Master (if the team is using Scrum) to focus on supporting the team's day-to-day activities and leaving the team to coordinate its work internally.  It's often very hard for people who are accustomed to a traditional PM role to make that jump and let the team have space for self-organization. 

Tell us a little more about what you do as a LEGO Serious Play facilitator.

I love doing LEGO Serious Play - I wish I could spend all my time running LSP workshops!  LEGO Serious Play is like play therapy for business.  It's a very simple, structured process that enables people to have really important conversations about how they're working as team or to share ideas about the work they're doing in a way that is designed to help them get to the heart of the conversation very quickly.  

How an LSP session works : the facilitator asks a question, the participants build a model to answer the question in a very short period of time, and then each person at the table shares their story about the model with the others. This process is repeated a few times to build up a shared understanding of the subject at hand that incorporates the viewpoints of everyone taking part. A longer workshop may involve fitting the individual models together in an integrated landscape to really create a shared view of what the aims of the group are. 

It's simple, but incredibly powerful.  Because people are using their hands as well as their brains, unexpected ideas emerge.  Time-boxing the builds forces a focus on the most important ideas.  And seeing the ideas take shape on the table results in a different kind of understanding about how the pieces fit together.  I use LSP for everything from team building sessions at the start of a project, to strategic visioning and planning, to retrospectives.  

I've written a bit on my blog about how LEGO Serious Play works.   I tend to overuse the word "magic" to describe the results of LSP, but every single time I run a session I'm blown away by what ends up on the table.  People are often very skeptical before they've used LSP to do work because it seems silly and not serious, but once they've taken part in an LSP session they realize how incredibly powerful it is as a tool for helping people to express what's in their heads and their hearts.

When working with organizations how you do come up with a strategy?

My Agile coaching strategy is fairly simple:  1) Help the organization figure out what they're really trying to accomplish, and then 2) help them find ways to get there.   This sounds easy but usually is not, especially in larger organizations where there is often ambiguity and conflict in what the real goals actually are.  With small teams/companies, there's usually a clear set of desired outcomes driving the team ('Make customers happy so that we make money and stay in business').  With larger organizations, especially in the public sector, it's often much more complicated to understand what the actual goals and desired outcomes are. "Get the project done" is a fairly meaningless goal unless you understand what the real value to be delivered through the project is and who you're delivering to, but large public sector projects often fail to communicate either of those things to the people who are doing the implementation work - the message conveyed to the team is usually "Here's the requirements, just get it done!".  It's very hard to transition to an Agile way of working in those kinds of organizations.

What are the 3 things you would suggest to all Agile project managers? 

Focus on the value being delivered through the work, not the meeting the expectations of the plan. Inexperienced PMs sometimes lose sight of this and confuse "successful delivery of project artifacts" with "a successful project".    It doesn't matter if you deliver on time and on budget if the end result doesn't please the people it's meant for. 

Trust your team to do the right things (and tailor your behavior accordingly). People tend to live up to what's expected of them, and if you want to encourage responsibility and accountability in your colleagues, you need to treat them as responsible, accountable individuals with good intentions and good judgment. Most people want to do great work - and if they don't, taking a command-and-control approach to managing their work won't result in happiness for anyone. If they do want to do great work, a controlling approach is just going to get in their way.

Make it safe for the team to fail. If you don't want the bigger effort to be a failure, you need to help create a culture (at least within the team) where it's OK for people to make mistakes and to ask for help when they need it.  I've seen too many big problems that were caused by smaller problems being ignored or hidden because team members weren't comfortable being open when things went wrong.  I'm a big fan of the "Failure Bow", because it's so much better in the long run to handle failures well instead of blaming-and-shaming so that we can learn from mistakes.

Thank you Ellen.

(Pic Courtesy: Ellen Grove)

The Broken Glass Theory: And What You Can Do About It

The Broken Glass Theory was introduced in 1982 by social scientists in Atlantic Monthly which says if there’s a broken window in a building, chances of breaking more glasses has a higher chance than in a building with no broken glasses. 

So as project managers, the goal is simple- fix things as soon as possible lest the rest of it gets broken too.

When you look from a team perspective, the goal is to ensure if you find something broken or out of order, address it immediately by having a one on one with the team member and seeing how you can help in the process.  The problem with not fixing the problem is that it will become a bigger problem when its gets too complicated to handle it and will create a furor in the team environment.

If you see the from organization culture point of view, not resolving or looking into the issues make it evident to the rest of the team that its okay to engage in these disruptive actions and management accepts it. This definitely send a wrong signal.

Address the trouble maker immediately and send the right message to your team, to ensure the process and work culture stays in place.

However, there is another research which shows that the Broken Glass Theory doesn’t work and the theory works because of dependencies because of some other action that took place.

Whether this reduces the crime rate or not (theory comes from criminal perspective), it definitely makes sense from the team handling. Leave a team with problems and it will only grow bigger and unmanageable.  

(Pic Courtesy: Google Images)

Agile Managers- what should you do?

“A leader is best when people barely know he exists. When his work is done, his aim fulfilled, they will say: We did it ourselves.”  -Lao Tzu

Simple things create the greatest impact. As Agile Managers, the goal is to ensure your team is groomed, mentored and ready to take up any challenges.

To do so, you also have to lead by example- you should be able to:

• Inspire
• Be supportive
• Be empathetic
• Be honest
• Be objective

So, your focus is always to keep the team out of crisis so they can function at their optimum velocity.  Deming in his “14 action point guide” points at how one can get anyone out of the crisis mode. If you look at them, the main things to consider would be:

• Creating constancy of purpose- it’s important during any time or during any transformation process to let your team know about the purpose and why what is happening. This avoids the most important confusion of team members being insecure, going through a loss of direction and not being comfortable with the change. 
• Improve constantly- managers role is crucial here in keeping the theme of improvement going always. If you can inspire them in a one of a kind way, it has to be by dispersing the common message that every team member collectively has to improve. You can measure improve in various ways- by seeing team velocity, by seeing quality of the deliverable, seeing the team dynamics or seeing the happiness index of teams. 
• Drive out fear- encourage people to express freely in your organization and team. Even if the feedback is negative- against the process, against the team or may be against you- it allows you to know the reality. You can only know how to respond to and what strategy to implement if you know the genuine problem. 
• Remove barriers that that rob people of their pride to workmanship- inspiration for any work when intrinsic is way more productive than when its extrinsic. If you can find out what motivates them, what keeps them going, it’s just way easier to know their intrinsic motivation. I have worked with teams, who at some point got bored with the same kind of user stories in their backlog and wanted a change. In such situations just ask what they would like to work n, or what motivated them, One team wanted to take more risks at their work because they thought otherwise it gets boring; they did risk in one of the sprints against their committed stories and still finished really well.  The team member just find it motivating enough. 
• Recognition for their efforts for some is very important- just by simply saying  a ”thank you” or recognizing them during daily stand ups is enough to keep them happy and it doesn't take a lot of time or money! This point actually came up in one of my happiness index surveys with a team and since then I have always tried to recognize members for their efforts, no matter how small they are! So, during retrospectives, we make a point that the team thanks other team members by simply writing n sticky notes about them and then we tack it in the cubicle walls. 
• Put everyone to work- because transformation is everyone’s job; especially if you have adopted agile very recently. No one should feel that their part is for granted or not important. Keeping everyone involved is the most tricky part when going through transformation. And this is something only managers can do. You can work with your Agile consultant/coach on these scenarios, however you have to make the final call.  As a manager you have to let everyone now how they can be involved, contribute actively and help management make decisions.  

(Pic courtesy: Google Images)

Scrum Gathering Pune

This post comes in a bit late I guess, mostly due to malfunctioning internet of my phone at the seminar and travelling next few days.

The Pune Scrum Gathering was bigger than I had expected, lots of people from all over the world and a location that was at grand as the event! 

The keynote speaker was someone I knew and had read his blog for years. To see Jurgen Appelo in person was nice and it was one of the best presentations in the 2 day event.

Most of my 2 days was spent with my colleagues, sometimes in the seminar, mostly just helping them out in the exhibition stall that was put up- just chatting up people who stopped by and answering different kind of questions.

By the way, I did manage to get an autograph from Jurgen Appelo, last one was from Elizabeth Harrin. I am still old fashioned that way!

The sessions have something for everyone- from real life case studies to new methodology to theories about latest way of using them in industries. So, whichever level you are in; you get to learn. Breakfast and lunch was good, so was the opportunity to network with hundreds of others and learn from them.

I enjoyed most of the sessions I could attend, some more than the others like that of Nancy Sharma.  She brought n the behavioral traits required in an agile team and unlike others she handled questions during the presentation, went back to it with aplomb and brought in amazing insights form the real world on how to encourage the team culture in an organization, how to handle loners and naysayers along with the so called heroes.

While this was my first visit to Pune, I loved the city and will return definitely. I enjoyed meeting up a friend over an Italian dinner after 10 years, meeting his wife for the first time and talking late into the night listening to stories on how they had met. The next day evening was spent with colleagues and client over an extended dinner.

Here are more pictures from the semnar in case you are interested.

Scrum Gathering Pune (India)

The next 3 days will be pretty fun. I am heading out today for the Scrum Gathering Pune and will post updates, pics and lots of chit chats in the blog.

I am looking forward to listening to some great minds including Jurgen Appelo

So, stay tuned for the latest updates via the blog and twitter (@Soma_b)

Interview with Agile Coach Derek Huether

Derek Huether is a Agile coach and over the last 25 years has held titles like U.S. Marine, Start-Up Founder, Project Manager, and Federal Government Project Management Office (PMO) Advisor, helping start-ups, private corporations, educational institutions, and government agencies. He has been involved with the PMI-ACP development process since the PMI North American Congress in 2010 and has transitioned to a new role as Co-Lead of the PMI-ACP Support Team. His book "Zombie Project Management" is available on Amazon.

How did you move into Agile Coaching? 
I used to be a traditional project manager, doing my best to deliver software projects following a waterfall process. I could do it but it wasn't easy.  I discovered taking a disciplined iterative approach got more to the customer earlier.  In the end, I was able to have more "successful" projects, leveraging iterative and incremental approaches.  I began evangelizing these methods to my customer.  Over time, I realized I could do more good if I coached more organizations than just a few internal teams.  And so began my coaching career.

When you are working with teams and organizations  and transforming them into an Agile organization, do you see a lot of resistance specially if they are moving from waterfall methodologies? How do you handle those situations?
I've always seen pockets or resistance, regardless of how badly an organization or team say they want to become an "Agile" organization.  If waterfall is working for them, I'm going to ask why they think Agile will work better.  Depending on the culture, they may have limited success trying to leverage Agile.  As the character Morpheus said to Neo in The Matrix: ...I can only show you the door. You're the one that has to walk through it.   They hire us to show them the way.  I can't force them to change.

What according to you, is the ONE quality that Agile coaches shouldn't have?
Dogmatic beliefs

As a co-lead for the ACP Support Team for PMI; how do you think getting the PMI- ACP certification creates a differentiation for a professional from other available certificates in the market. How important is a certificate?

If you're looking for a new job, unfortunately, certifications are what HR departments are using to find people, rather than actually seeing if they are a good skill and personality fit.  As certifications go, I think the PMI-ACP is well balanced and I like the fact that you need previous Agile experience in order to quality to take the exam.  Some other certifications don't require any previous experience but HR departments either are unaware of this or don't care.  One differentiator of the PMI-ACP is that it certifies you as a Practitioner, not a Master or Professional in the given domain.  

How should a team get ready for a transformation, so they are ready to co-operate with the coach and participate in the change?
They just need to be receptive to change.  They need to have an open mind. They need to be honest with themselves and the coach.

Pic Courtesy: http://thecriticalpath.info

Changing to Agile: How to handle the move

When you or your organization is trying to implement something new: a process, new rules, new way of working; there will always come with the good and the bad. There will be too much enthusiasm from some, and negativity from others.


However, when you have to get something done, you better be prepared and get it done. If it’s about implementing Agile here are some things that will help you get through the storm:

• The Non- Believers- change is difficult for most and it’s okay to have a percentage of non-believers. They are the ones:
• Who will question your every move
• Have a comment every 10 minutes
• May be even be vocal to the extent they question how it will help their team or organization
• Sometimes a bit rude

Having them will always keep you on your toes and it’s a good thing initially, don’t get frustrated by their behavior  the attitudes or even the negative comments. Take it up as a challenge, prove them wrong and they will come around.

• The Team Members- The team members will size you up, look for your weaknesses,  find a way to make sure you snap and be on your side while they bash you publicly. There are 3 kinds of team members:
• The receptive ones- some of them will be open to the change and ideas that you bring. They can be the one who are frustrated with the way the team/organization has been working so far. They are also the one who want things to improve, in a way there are the positive influencers and on your side. Always keep them happy and listen to them.
• The shrug(gers)- they are ones who will shrug their shoulders every time you ask for a suggestion or opinion. They don’t care about their team, they are the ones who focus on themselves and their work and their sentences start with “i”. Watch them closely and find ways to learn more about them. 
• The blockers- they start every sentence with a negative vibe, they ensure their opinion is always heard, are attention seekers and will try to find ways to block your work and ensure it fails.

• The Scrum Master- If the organization has been using Agile, scrum masters are already there and most of the majority might not be very co-operative from the very first day. Everyone has a style of their own and the last thing they want is someone from outside to come and tell them what to do. The best way to deal in such situations is to:
• Just be an observer for the first sprint- don’t interfere in their way of working. Let them be. Instead look up the backlog and find ways to make relevant conversations happening. Ask why a task is blocked, or why it isn’t updated etc. This will open up a conversation without interfering with their work. The goal is to have the scrum master talk to you and start listening to you. When in doubt, the SM will ask for suggestions- give suggestions which are open. 
• Don’t over ride the SM in front of the team- let the SM be the one in limelight. Let the SM feel that you as a consultant or coach are not a threatening them in any way. 
• Be on the side of the SM- talk often on a one to one basis with the SM to discuss any concerns from both sides. Objective is to ensure the SM is talking more than you are.

• The stakeholders- like most team members stakeholders differ in their opinion. Some have sponsored the change, some want to have it because everyone else is doing it and some give in because they don’t want others to think they are the negative ones.

• Stakeholders while going through transformation are 3 types:
• Confirmed- the confirmed stakeholders are those who are sponsoring the transformation. These are the names that are known to you, who will meet you from the initial days and is your support for the transformation.
• Floaters- these stakeholders come and go. They are the stakeholders who will support, however you need to convince them that the change is going good. 
• Hidden- these stakeholders are those whom you need to find out. They might not be the official stakeholders, but these are the people who can influence the primary stakeholders. So keeping them informed and buying in their support might be a great way to get the go ahead light and support in the transformation process. They will help you when in problem, find you the right person to talk to and even personally take the initiative to support you in every possible way. These stakeholders are the most difficult to find and are the most useful.

Bottom line, keep your eyes and ears open and it’s all about handling your team and the individuals than anything else.

To learn more about 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.

Pick the right person to mentor

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.

5 ways to get your team to adhere to the incoming change

Change is good. Change is difficult. Change leads to more change.

And you are going through a change with your team- could be team shuffling, can be inclusion of distributed team members, can be a transformation and you want the team to stop worrying and be at ease.

Here are few ways to get it done:

• Provide enough information to stop the panic-If you already know the road map  share it with your team, so no one is in panic mode and work continues. Make sure you answer questions, share your vision and keep them engaged during the change.
• Communicate often- Talk to them on what’s bothering them, look for honest feedback, listen to their needs and keep the communication open. Set up a communication plan with your team- a meeting once  a week or an email update that goes out on Friday 5 pm.
• Naysayers- Keep them in the communication loop. It’s easy to spread discontentment and negative word around much faster, so make sure you know what’s going on at the water cooler.
• Mind your Body language- You don’t want to be the manager who says something and believes in something else. Before you go out on an information sharing crusade make sure you know what you are talking about and know it well to filed any questions coming your way.
• Acceptance- If you want your team to accept the change, make sure you create an environment that allows them to stay positive and get all the right information at the right time. 

(Pic Courtesy: Google images)

To learn more about 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.

10 easy steps to implementing Scrum

 Agile has taken over the project management world and there are more and more companies that are jumping in the bandwagon.

If you are new to Scrum, here are 10 easy steps to start implementing it (taken from All About Agile):

•Get your backlog in order
•How to estimate your product backlog
•Sprint Planning requirements
•Sprint Planning task
•Create a collaborative Workspace
•Sprint
•Stand up and be Counted
•Track progress with Burn down chart
•Finish when you said you would
•Review, reflect and repeat

While you get your Scrum in order I will be away for a short break and return on April 16!

Interview with Scrum Coach- Dhaval Panchal

Dhaval Panchal is a certified SCRUM coach and trainer based in Seattle. With a background in software development, business analysis, lean office implementations, system architecture, and project management – he has moved on to become a successful coach. While his background in project management still helps him out, his greatest payback as a coach is the opportunity to interact with people from diverse backgrounds and learn from them.

You worked in IT and then moved to SCRUM coaching, tell us how this happened?  

Fresh out of college I was hired by one of the tech giants in the Indian IT space. Within the first four years working with them I was completely burned out and mostly disheartened with the antiquated management practices and  “chalta hai” management approach. The morale was extremely low and many passionate intelligent peers either escaped to B-Schools or found alternative employment opportunities. I was prepared to leave the IT industry but was hopeful that there is a better way. I interviewed and got hired by my present company (8 years ago). They were pursuing scrum and extreme programming (XP) as alternatives to build software.

I started scrumming and played variety of roles in the projects that were outsourced to us. In each of our outsourced projects I actively pursued and attempted to influence my client’s understanding of scrum. So in many respects I have always been coaching. 

To me coaching is a skill and not a title. With the explosive adoption of scrum in the IT industry, for the last 5 years, I have been involved in change management helping to transition organizations to an agile business and delivery model. My coaching skills are extremely useful in helping my clients cope with the pain that accompanies any organizational change.

Do you enjoy working as a coach- 3 things you wish you knew when you started coaching.

• Listen more talk less -We all have two ears and one mouth. It took me a while to realize that I should be using them in the same proportion. Earlier as I would engage in a conversation when hearing the other, mentally I would be calculating a response even before the other person has finished speaking. This analytical bent was a huge handicap and as I have progressed to improve on my listening skills I now tune into the person speaking and their context to appreciate their situation. Often times people talk themselves through their problem and appreciate my patient listening that helped them through.
• Coach the person not the problem- IT is a problem solving field and the industry is self selecting for people who can solve problems. This has ironically led to a common pattern. “most people in our industry can tolerate a problem but cannot live with a solution that they do not understand.” This erodes trust and is detrimental to people’s ability to own and resolve their own problems. As I engage with my clients in complex IT  and people change management issues I intentionally stay away from prescribing solutions and focus on the person and help them sharpen their problem solving skills. It is more about teaching a person to fish than catching a fish for them.
• I can always walk out- I take a lot of pride in my work and aspire to better myself. It took me a while to recognize that I do not have to be a good fit for everyone. Now I recognize situations and people better where I may not be a good fit as a consultant and choose not to engage.

Tell us any incident or moment of inspiration that has kept you in coaching.

Being a catalyst to help form high performing teams and great products is my passion and I have a lot of heart for enabling organizations and people to find fulfillment in their pursuit. Although there isn’t any specific moment or incident, it is an heart warming experience for me to hear appreciations from people who I had worked with many many months ago. To be remembered, recognized and appreciated for my work long after my work is done is my greatest reward.

Do you use your experience in project management for your coaching now?

 
Yes, my experience in project management is helpful for me to appreciate the context of PM folks who are interested in agile product delivery approach.

A lot of traditional PM style and approach is anti-agile and requires much unlearning to break away from the command-and-control mindset that fosters a belief in magic. Getting to deal with the day to day realities of product delivery and the challenges is overwhelming and the realities of innovative rapid product delivery cycles demand a high performing team of individuals as opposed to the “hero” project manager that saves the day.

Getting PM’s to abandon their heroic pursuits and collaborate as peers in a team based context is a challenge where my past background with PM comes in handy.

Where can we find more information about your coaching? 

My blog: http://dhavalpanchal.com

Thank you Dhaval!

CPR Technique

This post has been taken from http://www.dhavalpanchal.com

The software world has misused so many terms from the medical profession that one more would not hurt.

CPR – Categorize, Prioritize, Resolve.
This is simple mnemonic that aids me to be methodical in my approach towards uncovering and resolving impediments.

Categorize:
How do you view your world?
To me lack of impediments is like moving in a frictionless environment. This state exists when
a. No work is being done
b. It is an ideal theoretical context

To challenge myself and my teams to look beyond business as usual, I look to creating a categorization mechanism that people can relate to. Lean concepts of load, flow and waste are very simple to understand and use.

There are other categorizing perspectives such as
1. process, tools, technology, culture
2. Not enough time, Takes a lot of time
3. Personal, Team, Organizational
4. Stop, Stall, Go!
5. One off, Always, Sometimes
There are no limits to how you may slice your world of work, expose perspectives and uncover impediments that were hidden.

Prioritize:
The purpose of prioritizing is two fold:
1. Identify impediments that have most negative impact on having ‘fun’ at work
2. Select a handful of impediments that should be worked through resolution.
For impact assessment, ‘dot-voting’ could be a technique to bubble up impediments that sap most energy from your team. (As has been done on the picture above)
Many impediments get treated as ‘Business as usual’  - often times because people are not sure how to influence or act towards resolution. Impediments that get ignored or not addressed fall through the cracks and ignored and accepted as norms for team/organization culture.
Recognizing where the team can take action, where they can influence and what is ‘the soup’ is very important to focus on what can be done over what should be done.

As a self directed exercise, the team members move impediment stickies to into an appropriate zone. Items that they feel they can act upon and attempt to resolve within the team fall into the ‘me’ circle. Items that can be influenced and require assistance from managers, organizationals, other teams etc fall into the influence zone. Items that can’t be acted upon or resolved via influence are in the soup. Many organizational scale impediments tend to fall into the soup.

Resolve:
Take action on resolving impediments that are in the ‘me’ zone. Act towards influencing others in your organization to assit with impediments in the ‘influence’ zone. Expose impediments that are in the soup to senior management, as they are best positioned to address these.

Identifying problems have a negative impact while resolving problems have a positive impact.

Scrum

Details on Scrum and everything you need to know.

CSM (Scrum Certified Master) 

Requirements include:

·         Familiarize with scrum basics

·         Attend CSM course

·         Asses your progress through online evaluation.

CSP (Scrum Certified Professional) 

                Requirements include:

·         Download the application  and illustrate hands on experience

·         Send the complete application for review and approval to the Review committee.

·         On approval you pay $250  for certification fee

CST (Scrum Certified Trainer) 

Requirements include:

• Have a solid understanding of the Scrum framework, a deep understanding of the principles and values that are the foundations of Scrum, and a clarity on what belongs to Scrum and what is an extension or complement;
• Have extensive experience of implementing and/or coaching Scrum inside organizations;
• Be active in the wider Scrum community, through actual and virtual interaction with other Scrum and Agile thinkers and practitioners;
• Have training experience beyond just Scrum, be willing to explore new ways of working and be committed to continuous improvement.

SCC (Scrum Certified Coach) 

 experts in Scrum, both in theory and in practice. They have an in-depth understanding of the practices and principles of Scrum and have real experience on actual Scrum projects.

• Does your ScrumMaster need a mentor?
• Does your Product Owner need help learning how to work with a product backlog?
• Are you having trouble breaking sprint backlog items into task lists?
• Are your sprints consistently ending with unfinished work? 
• Is estimating so hard that your sprint planning lasts beyond its timebox?
• Does your management underestimate the scope of organizational change necessary for Scrum to be successful?
• Are you facing challenges with multi-team Scrum projects?
• Is your organization having difficulty implementing the Scrum framework in conjunction with other methodologies?
• Is the team encountering obstacles with organizational impediments?
• Does your organization need coaching and guidance on scaling Scrum?

And there are more, you can also be a Certified Product Owner or developer.

More on Kanban. 

Scrum Certification- Lessons Learnt

“Having coached many software development teams, I tend to value my contribution by what a team does when I’m not with them over what the team does when I’m with them.”
                                                         - Dhaval Panchal, Agile Coach and Trainer (source)

Trainings are supposed to be boring.

Unless something wakes you up. Or you are in a class that is surprisingly interesting.

Last week, I happened to be in one.

It was training and interesting-a scrum certification class (CSM) conducted by Solutions IQ.

If you are already certified in scrum or have taken courses you know the drill. If you haven’t, you can look over here .

You don’t have to choose either/or between a PMP and a CSM/CSP- you can be both. Scrum training actually offers you PDU’s as well for attending these classes. Cool!

I have heard so much about Agile and Scrum that I genuinely got interested and decided to go for it. You can check for nearby classes based on your location by looking into the website.

That’s how I found mine and it’s been a treat and I’m sold to Scrum. So much so, that I started my own board at work to monitor my work and see if it helps. Oh, I also have one at home for my personal goals stuck behind my study door.

Seattle based Dhaval Panchal  has been an awesome trainer for the 2 days of training in Hyderabad, India – informative, knowledgeable, patient, helpful and always approachable. Given a chance I’d train with him again.

My favourite part of the class was the Paper Ball game- it teaches you more about the team dynamics than you would think. A group of random people who met 15 mints ago  and has to abide by the rules of the game, severe time constraints and expectation of an end result can take the so called managers in for a spin. Who takes the control, who listens to whom, whose idea should be implemented, why am I being Ignored......the behavorial drama continues.

A class worth attending for sure. Thank you Dhaval.

(Disclosure: I paid for my certification; it wasn't sponsored by any organization). 


Pic Courtesy: Google Images.

Agile Books

Want to know more Agile, browse through the list of best top 20 best Agile books.

Or simply read the 10 principles of Agile Time PM and understand the Decline and Fall of Agilists

Thanks to Jurgen Appelo.

Micromanagement and Agile

Keeping inline with the Agile week, here is a discussion if Agile is all about micromanagement.

Thanks to Joelle Godfrey's blog, thats where I found the link. Clearly my learning through twitter is working. At least thats what I think!

What is agile?

Interview with Raj Menon, the author of http://leadership.13apples.com/.

We talk about Agile and what it takes to be the Agile Expert. Here's a prelude to Agile before you read the interview.

We hear so much about Agile and Scrum- what’s the difference between them?
Agile is a software development methodology which is an alternative SDLC "better" than Waterfall, iterative in nature and encourages teamcollaboration, accountability and trust. SCRUM is a framework that helps execute agile software development. SCRUM emphasizes on enabling a self-organizing multi-functional team to work on prioritized tasks in 2-4 weeks cycles called sprints.

If you wanted to be an expert in any of these, how do you think oneshould go for it?
In my opinion, one does not become an expert in SCRUM. One can only try to follow SCRUM to the best of their knowledge and abilities to bring about a fundamental change in project and people management.

SCRUM is simple in concept but tough to implement. Why? Because changes are tough and it takes time, patience and persistence. Has anyone ever become an expert change agent? I don’t think so coz change is so dynamic in nature that whenever you go about changing something or someone, it is a new struggle every time. If you truly learn and follow SCRUM, you are a change agent. Your objectives are simply to change the way projects are managed, the way teams are organized and valued and make success a repetitive reality.

What are the pre-requisites for the Certifications?

• A genuine interest to bring about a fresh perspective to software development.
• Two days of free time
• USD - $600 if you take it in India and $1300 in States

That is all you need to go in for CSM certification training.

How difficult was it to take the exam after just taking classes for 2days? Is that all the preparation you need to take?

This is a question everyone who is interested in SCRUM certification seems to be commonly wondering/asking. Yes, 2 days of training is all you need to learn and fall in love with SCRUM. In these 2 days you implement SCRUM from ground up and you practice it. You end up learning a lot and most importantly you will question your fundamental beliefs and learning’s from the past.

Any suggestions for taking the exams?

I have not taken the exam as I got certified in an Aug'09 batch, much before the exams kicked in. However, my suggestion to those who are taking the exam would be to pay full attention in the 2 days of training and ask as many questions as possible, even if you think it may sound silly. Keep an open mind. If you do, the exam should be a breeze.

On a personal note, how did you get into project management?

The right environment, the opportunities it provided, the leaders who mentored me, my confidence in pursuing challenges without the fear of failure, an ambition to grow, the desire to bring about changes, and my people management skills - are some of the main drivers that got a ASP developer into project/program management. It was a calling.

I know you blog, so what does your site primarily focus on?
Yes, I blog to feed my passion to write. My blog is called http://www.13apples.com/ and focuses primarily on leadership from every walk of life - from my experiences to my thoughts and observations of leadership that I believe is all around us. The site is also a source for Toastmasters speeches and articles on public speaking, communication tools and techniques, team building, team motivation and now Agile/SCRUM.

To know more about his experience, read this.

Raj Menon, the creator of 13apples.com (formerly known as lap31) is a Program Manager by profession and Leadership Blogger by passion. He explores the mindset of a leader and what it takes to be one as he shares his own experiences and thoughts through his writing. Follow Raj on Twitter.
(Pic Courtesy)