Showing posts with label agile coaching. Show all posts
Showing posts with label agile coaching. Show all posts

Interview: Authors of A Guide to Distributed Agile Framework

The book has been recently published in Amazon and if you have heard of Agile, work as part of Agile teams or would like to have  a better understanding how to make it across countries to work as one team- the challenges and the tools that will help you bribe the gap, this book is for you.

Today we are interviewing the authors of the book: John Okoro, Savita Pahuja and Hugo messer. 

1.First of all congratulations on the book, tell us how did three of you meet and decide to come up with the book?

John: We met on-line through shared interests, and at the Agile Singapore 2016 Conference. 

Savita: Hugo was already working on distributed agile blogs, models and mini books. When we met and discussed the topic, we figured out the common interest and experience on this topic. That’s how we decided to write a book.

We always wanted to share with the community our experience as well as experience of other people working in this space that’s why we have many practices shared by people in the community. 

Hugo: A few years back, I ran a podcast around distributed agile. The interviews with Savita and John inspired me and later, in our discussions, the idea of writing a book about it popped up. We initially started with 4 authors, but one was too busy to continue the effort. The initial idea came up as we saw ‘distributed’ was never answered fully within the agile community. Most frameworks touch upon it, but always look at distribution through their framework-lense. We thought it would be interesting to help address the specific challenges that come up when working distributed. We spoke to many people who struggled with it throughout the years. In my own company, Bridge, I have always had challenges with the distribution across Europe, Ukraine and India. With the book, we mean to help provide people solutions to these challenges. 

2.  You talk about the 6 bubbles of a distributed team, why are they so important to you?
John:  Many Agile teams struggle when it comes to working across countries or locations.  Having guidance and the experience of other distributed Agile practitioners is an important first step.  The bubbles are a good way to organize these ideas for easy consumption by our readers, and practitioners. 

Savita: These six bubbles are the main areas where teams struggle particularly when they are distributed. If organisations want to overcome the challenges of distribution, they should focus on all these six bubbles which are: 
Teams and tools

Hugo:The issue with distribution is that people see the ‘problems’ in other areas. For example, they believe they need to become better at ‘agile’ or ‘scrum’. Oftentimes, scrum doesn’t work perfectly because teams forget that culture influences their collaboration. Leaders forget that to grow a distributed organization, they need to organize work in a different way compared to ‘local agile’. We discussed what were the main ‘influencers’ of agile collaboration across the globe and summarized it in these 6 bubbles. We had more earlier, but since less is more, we simplified it to 6.  

3. Throughout the book you focus a lot on culture and the stories around it…what would you recommend the top 3 action items for any teams who work in distributed mode?

  1. Meet face to face at least once, there is no underestimating the power of building an in-person relationship. 
  2. Ensure there are truly Agile leadership virtues like servant leadership, empowering teams, and a growth (Agile) mindset in the organization.  With these Agile leadership virtues and the related practices in place the team is off to a good start. 
  3. Have collaboration tools in place like virtual electronic Agile Boards, Wikis, Virtual Pair Programming tools, DevOps tools to provide dependable and fast builds and deployment.  We talk about practices, and other tools that support distributed teams like high quality video conference. 

  1. Create ‘one team’. No matter where people are and what company they work for, ensure people see their common ‘product/goal’. Have coaches to foster that ‘one team’ spirit
  2. Make sure people have a ‘rhythm’ in which they meet face to face as often as possible + they use high quality video and audio to communicate throughout their sprint cycles. 
  3. Get leadership support in order to get to the right team structure (onshore roles versus offshore roles). 

4. Tell us what is a team canvas and the benefit of having one?

Savita: Alex Ivanov and Mitya Voloshuk present a model called Team Canvas for team alignment that we find useful to align everyone on goals, roles and skills, values, rules and activities. The Team Canvas is a Business Model Canvas for teamwork. It is a free tool for leaders, facilitators and consultants to organize team alignment meetings and bring members on the same page, resolve conflicts and build productive culture, fast. It becomes more important to align team members on these attributes when they are distributed. It also creates a level of understanding about people on other site that improves collaboration. 

5. The team room with the wall as a focal point is wonderful, tell me how to convince a team what they can expect when they have a team wall?

Savita: Team wall is one way to improve transparency in the team. It is also helpful to align everyone on the common goals and the work they are doing. It keeps on reminding people on the agreed stuff.

Human by nature is visual and many studies have proved that visual information stick in the memory. That’s what team wall gives to the team. 

Hugo: Transparency and visualization are key in Agile. Without the traditional requirement documents, teams get lost. Team walls and other portfolio/product visualizations help teams to see the big picture of a product, the roadmap, the users, the progress, etc. 

6. Do you think through all these discussion and points, the goal is to bring the members of the team to a common understanding and set up an understanding  that leads to better quality work?

John: Our goal is to bring relevant perspectives and experiences, that are distilled into a set of virtues, questions, and practices. These can be used by our readers to continually improve (Kaizen) and help their distributed Agile teams to succeed. 

Hugo:  Yes I believe so; if we don’t have the discussions proposed in our book, people will blindly execute; business as usual. By becoming more aware of the specific challenges inherent in cross-country-work and having clear action plans to address them, teamwork and hence quality will increase. 

7.  Do you think the concept of distributed culture and its working agreement depends on team maturity? How should one overcome it?

John: Every distributed Agile team is different.  We suggest that teams should come up with their own working agreements that are suitable for their own teams.  If a team is very mature it is likely they will very easily agree to and follow their team working agreement.  On the other hand, newer, less mature teams may need more guidance from a ScrumMaster, Agile Coach or facilitator to stay in alignment with their working agreements. 

Hugo: It surely helps to have mature teams. If I am a junior and just join a software development team, I don’t know yet how to be productive, how to communicate well, etc. As I don’t know that yet even for a local context, working in a global team will bring a lot of challenges. If we have a mature team with experience working in agile for a couple of years, they’ll more easily adapt to the global setup. 

Thank you for your time for the interview.

To buy the book click here.

If you are like this interview, you might also like 44 other interviews done right here. If Agile makes you happy, click here. 

Why is creativity important in agile?

Majority of teams and organizations believe, agile is about ceremonies and productivity and leveraging the flexibility by forcefully changing requirements and showcasing books and authors on how it has been done.

 In ‘Building the Agile Business’, author and digital strategist Neil Perkin describes an agile business as being ‘velocity x focus x flexibility’. In other words, a business that is focusing its efforts on moving in a clear direction, but that also has an in-built ability to adapt and change course if and when necessary…..Taking an agile approach enables brands to test new ideas early on and to adapt easily to changes to ensure maximum success. 

In most scenarios this over used buzzword has also created myths around it that very few can differentiate with reality. Like doing stands up doesn’t make you an agile team. An organization isn’t Agile if only teams are forced to change without telling them why the change is happening. It only leads to bitterness.

There are the supporters and the naysayers who argue over whose agile (implementation) is better. They quote authors and books and bring out snippets of blogposts and argue their case. In all this chaos, I have barely seen teams question what they do and why they do? Why the change?
Creativity often ignored isn’t considered as mainstream thought process in resolving real time problems. The flexibility or adaptability in Agile is sometimes taken as a license to leverage it without thinking.

While certain outlines needs to be adhered, creativity or free thinking can always help resolve problems even when it revolves around process. The most creative individuals are those who can see the things that everyone else misses. 

Looking at data trends in an agile team can tell you where lies the core problem, to put an end to mechanical retrospectives and really finding ways to get the team talking needs creativity and to eventually see what’s working and what’s not and to better the team is about thinking differently.

So, should we incorporate in Agile training's about the need of looking at a set of problems  and thinking how to resolve by adhering to your team culture, by encouraging team members to come up with a new set of solution, bring the team together in discussing collaboratively and telling that it’s not about the tools, it’s about you. Bring you to the table, bring your ideas, disagree when required and respect the difference of thoughts. 

(Pic courtesy: Google Images)

Being Human in Agile

Agile is one of the most-discussed subjects in any process domain.

With commercialization and certification now so easily available to many, the approach has become easier to learn and implement, and with that has come the liability of seeing it as only a set of rules and practices. The "individual" who was the center of the process has now taken a back seat among the fancy tools and apps. Among many, Agile has become only a term.

As an Agile coach working with multiple teams and organizations, I have always felt that miracles are expected just because you gather together for 15 minutes. We look for data and stats and obsessively check tools. We have made the tool bigger than the process. Rarely does anyone talk about the human factor in Agile. No one wants to take the time to make the connections; we only want the productivity increased.

Have you ever noticed how you work your best? Let’s take a blind guess — maybe you like the freedom in the way you work, the human connection with your peers, and an understanding manager or mentor. No matter which process you are part of, doing your best work shouldn’t change.

If you are still old school like me and prefer the human connection, here are three ways to bring it back.


Don’t approach an Agile transformation with hard-set rules and terminologies. Instead, take the time to explain why, as a team or organization, you are going for it, what benefits you are hoping for, and the challenges that will be encountered. Tell the story of failures, recall the successes you have seen, how you have mentored or coached other teams, and the fact that every transformation is unique and should be treated as such.

Hear their stories, too; try to create a story card. Divide a paper in four quadrants and create your guided storytelling pattern. I have seen that when given a structure to tell a story — based on a question or an activity — people respond better, and it opens up a real conversation rather than just encouraging free-flowing conversation.

You can choose any of the following to create your story card for the teams and then talk one-on-one to understand them:

  • Myers-Briggs Type Indicator score (personality type): Try the free online assessment. This is just for fun and provides some insight into the person. Even if people disagree with the results, they will talk about why it doesn’t match up.
  • Moving Motivators: I find it interesting to see the most- and least-favorite motivators; it's usually an eye-opener. Asking the right question along with this assessment helps form some perspective you will need as a coach or manager to work with each individual. You can find the game at the Management 3.0 website.
  • Who you are: That 30-second elevator speech is rather difficult when you take out of the equation their job title or technical domain expertise. People really must think about who they are, and that’s what you want.
  • The improvement you would like to see in your team/process: Depending on their comfort level, people will talk. Trust me on this; you will get more information here than from looking at the trends in your team's velocity.

Mind Mapping
Sometimes we think better when articulating clearly, and the train of thought is easier to chase when we can come back to it. Mind mapping is a wonderful tool that can be used in various scenarios to get to know a person and to explain the process, and it can even be used in retrospectives. The transformation doesn’t need to be done in the same way everywhere. Learn about others and who you are working with, and bring new techniques to work that bring out the personal point of view and perspective.

Reactions will always change more when people see something than when they are told something over and over again. Instead of telling teams that they are full of flaws and that productivity and velocity have to increase, try value stream mapping with the team. Let the team draw with colored pens and crayons and have some fun. Then let them see where they have been lagging. When realizations come from within, changes are easier.

The bottom line from all of the above is that we are trying to keep the uniqueness of an individual and not trying to assume that everyone is the same. Data matters; however, you won’t know the authenticity of the data if the team is always gaming it up to protect themselves from you.

Yes, we are busy — always busy moving from one meeting to another. But not even for a second do we think that the human connection is replaceable with a process or data. When we showcase the human within us and try to understand the other person, it makes the transformation and the assumed role much more fulfilling for all.

This article was originally published in Scrum Alliance

(Pic courtesy: Google Images)

Tools- aren’t the answer to your Agile Transformation

The most hyped up idea during an Agile Transformation is the search for tool that would best suit your organizational needs. Tools is necessary, however isn’t the priority in your Agile journey.

In the process the focus shifts to the tool and then purpose of the transformation is lost. It reaches a point where transformation is equated with tool.

You don’t need fancy tools and a huge budget to start something small. Start your journey with a whiteboard, something that the team has to work on and can play around with it, changing and adding metrics or creating their own customized dashboard.

You can even try a team cork board, or use simple sticky notes or free software to try out the teams comfort level. Tool should be part of the process, not the process.

There are lots of reasons, why you fail in agile and tool shouldn’t be one of them. 
So, find ways to ensure you are Agile in reality. 

To know more about Agile tools, try the links here and here.

(Pic courtesy: Pinterest)

From the road and in between

May 24, 2015 | | 0 comments |
I have been trying to post and as is evident haven't been able to.

As a consultant I travel every week to another city (flight time 2 hours) and am back on the weekend. that has pretty much taken a toll on me and my time management skills. I have tried posting from airports, in between the crazy busy week  and sometimes on the weekend.

Reality is, I mostly blank out in airports and at 5am in the morning I don't feel like working on the blog. I am not a morning person at all. During the week the focus is more on the training's, work, reports, meetings and endless hours streamlined to keep things functional. Weekends is mostly mommy duty- Rio is 9 months old now and like all working moms I try to be with him when I can, as much as I can.

So, yes the blog has suffered in the process. However, I have been reading some good stuff and am sure will share it over here.

I hope in the busy schedule that you have, you get the time to sit down and relax and keep an hour for yourself. I honestly suffered with it, constantly travelling and working in deadlines. So, I am trying to force myself to relax sometimes, like I napped this weekend, didn't open my laptop until now, played with Rio and was  just happy to be home.

I hope like all pro bloggers I learn to write from airports, take mental notes while on elevators and can keep the blog going and make it look very easy.

Oh and before I forget in case you would like to help a fellow PM and one of my favorite people Samad on his research project and get a free cross cultural training, click here . 

(Pic courtesy: google images)

Adopting Agile Pt2- Who should be the scrum master?

Dec 3, 2014 | | 0 comments |
A lot of organizations and teams tend to appoint a scrum master for the team, sometimes against the wishes of the individual taking up the role.

I think it beats the purpose of transformation.

Appointing someone for the role can never lead to success. A scrum master as we know plays a crucial role during the transformation, you want someone who is interested, who will put their best foot forward and who’s up for the challenge.

Here are some ways you can look for a scrum master-
  • Provide enough information on what a role of a scrum master is and is expected
  • Talk about benefits of being a scrum master from a career perspective
  • Ensure enough support and training's for the scrum master who will take up the role.
  • Ask for volunteers

 Once you have a pool of volunteers or one per team, you can provide them with training's required to take up the role.

However, this role has its own classic confusion. Should a scrum master be a full time role or should it be part time along with your functional role. Some will have full time scrum master roles and take up multiple teams and some prefer part time scrum masters who are an integral part of the team and also works in their functional role.

I persnally prefer scrum masters who are an integral part of the team and understand the work and ins and out of what’s going in the team.  I also think team members accept scrum masters easily when they are part of the team than someone who is part of multiple teams and is more of a manager with a title of the scrum master.

So, who should really take up the role of a scrum master?
·         Someone interested (there is a learning curve)
·         Has social skills (taking care of impediments requires some)
·         Strong in communications (keeping the team together)
·         Has enough negotiation and convincing skills  (need that to interact with your product owner)
·         Is generally calm and not aggressive (when handling internal team conflicts)
·         Has a sense of humor (helps when dealing with the pressure of juggling roles and rebellious team members)
·         Can think objectively and not take sides
·         Determined to fix issues and keep the team together
·         Ability to think out of the box ( absolutely required when working with a smart competent team)

Well that might seem a lot, the good news is most of us have it in us. We have been trained and retrained to give up a lot over time and that might have clouded our out of the box thinking.  A nudge and encouragement can bring in the creativity back. And it improves with time.

The managers/management need to understand that the role though of a facilitator isn’t easy and needs time to settle in. Team members always don’t make it easy on the scrum master. So, give the time and encourage as much as possible.

Here’s what Mike Cohn says about being a scrum master  and an interesting article that talks about why the projectmanager is not a scrum master

You can read Part 1 of the series here

(Pic courtesy- Google Images)

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 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)

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.