Interview with Ellen Grove

Sep 9, 2013 | | 0 comments |
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?

Aug 19, 2013 | | 2 comments |
“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

Aug 17, 2013 | | 0 comments |


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.