Monday, August 10, 2015

One Week Introduction to Agile Culture: A Case Study


Today is Friday, and my first week at a new job is almost over. When I googled “first week at work”, I got numerous posts entitled “how to survive your first week at a new job”. Wow! – I thought, my experience was completely opposite, and here is why.

I joined company that builds software products using Agile framework - I knew that from the beginning. What I came to know is that they take pride in bringing Agile culture in and leaving it with the client when they move on - they refer to this as "high impact". And it shows. On my first day when I came to work, I was not sure where I sit… until I saw multicolored balloons and a welcome card signed by my new colleagues. Each of them wrote words of encouragement and wished me a lot of success in a new job. I felt very welcome.

Actually, I felt welcome much earlier starting with the day of my job interview where everyone was super friendly and sincerely interested in my career aspirations and professional strengths. This does not mean that the interview questions were simple and straightforward; they were very insightful, but it was a conversation where I was able to share my thoughts and skills and learn about the company and the people. Once I got home from the interview, I already felt that I have become part of a great team. There was ongoing communication until the day I showed up in the office and in addition, I had a chance to join everyone for a meetup on Node.js, so it already felt like home.

Today is my fifth day at a new job, and I already feel like part of the InRhythm family. How was it possible in five short days? First, it does not feel like five days. Everything happens fast here. I am in Operations, and our role is to support the teams working on client sites. We need to move fast, make decisions, and respond to the needs of our teams and the clients. We need to be nimble and efficient. We care about the people, the products they develop, and the clients they support. The team is like a family. What happens in a good family if someone needs help and support? The same happens here. Everyone is a leader taking ownership. At the same time, if there is a need, we swarm and get things done fast. One of the company’s values is that we hire and work with only the best, and this is true. Everyone is remarkable individually, and yet we are much stronger as a team.

The other interesting feature is how open minded everyone is. We use Agile to run the business, and when I suggested to try some new ideas, everyone supported this. Coming from the corporate environment, I am used to resistance to change and I was ready to face it. But I did not need to! Everyone was supportive and willing to try, and super encouraging. One my colleagues told me how much she appreciated the small changes that we introduced this week, and she said that while they were small, she felt they were helpful. Other colleague sent me a message that his standup experience has improved to encourage me, and immediately made further helpful suggestions. Everyone was receptive and willing to share their excitement and feedback. Transparency is valued highly here.

I can add that there is ongoing communication in the company where anyone can ask questions, make suggestions, simply support each other, and celebrate successes. Persistent chat and multiple other channels are used to exchange opinions and align on any complex issue. And – most importantly – everyone has a great sense of humor, so there is a lot of fun and jokes.

I learned a lot during my first week here. Most important is the ability to always work on the highest priority item and to be strategic about ow I invest my time. When I joined, I got a notepad where I can list three highest priority items I plan to accomplish each day. If an item does not fit within the three designated cells, do not do it. The way I prioritize my work is by working on high impact items, and never getting distracted with anything else. Working hard on a non-important items is worse than doing no job at all. This is a great approach which I was excited to embrace. It resonated with me, since professional success for me was always about bringing value - to the organization, to its customers, to my colleagues.

I can go on and on, but I think it’s time to pause, because it’s hard to describe the atmosphere of innovation, openness, and the friendly positive attitude everyone in the office brings in. I want to wish everyone who is reading this post to have a chance to experience such a supportive, open minded, and value driven culture in your professional life. No more ”how to survive the first week”, it’s my “best first professional week ever”! This is the impact of a true Agile culture and open minded transparent office environment where the team is swarming to achieve a common goal. I truly believe you do not need to be a startup to build a culture that embraces Agile values.

Wednesday, June 3, 2015

Agile Coaching is dead. Long live Agile practicing!



An exciting experience presenting at Big Apple Scrum Day 2015 and a great discussion about the future of Agile coaching as a profession. Full deck is posted here.

Wednesday, January 7, 2015

The power of the First 90 Days

Moving from a consulting job to a permanent role in a new organization is never easy. From a consulting role with an airline industry client to an Agile delivery role with a major health insurance company - comparable size (160K+ employees), corporate culture, multimillion dollar projects, agile at significant scale and yet, everything was different and new for me there.

Multiple challenges, ultimate uncertainty, lack of buy in, significant resistance, lack of trust, strong waterfall mentality - everything that we are so well familiar with as change agents coming to an organization as agile coaches and leaving as part of the transformed and high performing work environment leaving high performing and self organizing teams behind. I did not come to my new job to leave though, the scope was unlimited and the amount of work would last long enough for a long professional life span and well beyond. I came to enlighten, transform, and execute.

I was excited. I had great conversations at multiple job interviews that resonated with me. Agile at significant scale, like minded agilists excited about building products that transform healthcare and delight customers. I did my research, asked a lot of questions, and felt that I was well prepared. I spent my two days before joining putting my 90-day plan together. It was a no brainer. Build relationships, create the team, hire as needed, put together a transformation roadmap, socialize, get buy in, come up with a training and coaching approach, position the team externally, empower them, get them the tools, identify continuous improvement opportunities, decide on metrics, start execution, compare the baseline with the first few sprints' data, and celebrate successes.

Pretty simple for a 90-day plan. I wanted to assess the environment and start whatever would take me to change the delivery culture and mindsets at scale. I was excited about my 90-day roadmap! It was following the SMART (specific, measurable, achievable, result-oriented, time-bound) format, so each milestone had specific acceptance criteria and the timelines. For example, I was committing to building relationships by introducing myself to 5 people per day within the first 10 days, 2 people for the following 20 days, and 1 person the remainder of the 90 days. There was a breakdown which areas of the organizations these relationships should come from because I wanted to cover software delivery, project management, product management, business side of things and other dedicated teams. All thought through in minor detail.

I started with a lot of enthusiasm of an Agile coach who came to an organization to stay, to transform it from waterfall to the collaborative culture of ongoing delivery. I was thinking hackathons, product workshops, innovation weeks, collaborative spaces, agile at scale, multi-day PI planning sessions, changing the way healthcare is administered and perceived. My 90-day plan was translated into color-coded stickies and attached to the wall in my office. I was all set and ready to sprint.

The following 90 days were a torture. My 90-day release planning for a new job was forgotten. It was an ongoing never ending set of challenges ranging from archaic engineering practices to the process challenges multiplied by the high distribution rate for team members, lack of trust with the business, and ton of inefficiencies. But the people were amazing and teams were willing, and the product team was a fountain of ideas and suggestions!

So I did my version of Agile maturity assessment, spent a lot of time with teams and stakeholders and while doing that, met like-minded people and created multiple task force teams to address prioritized action items for continuous improvement. We made it a rule that every day we want to accomplish something, even though it may feel small and insignificant. And each time a user story was completed, I moved a user story on our kanban board to the right column tagged as "Completed". I worked around the clock, worked directly with multiple teams, and somehow things started moving. The teams moved into a cadence, became higher-performing, were moving ahead fast, implemented ATDD, and were plowing ahead overall.

So one day I came to work, checked stickies on my 90-day board and was stunned to notice that all the stickies are gone from the left and the right column has them all as completed. All my tiredness was gone and I was more excited about my Agile delivery role than ever. The teams within my portfolio are not highly performing yet, but they are developing quality software at cadence, they are collaborative, innovative, empowered. Their technical maturity is growing. Team members work at sustainable pace. I looked at a calendar, and - surprise - it was exactly 90 days since I started my new employment. All of a sudden I realized that I've completed all my user stories - my 90-day sprint was not wasted. Just like Michael Watkins says in his book, "The First 90 Days", it is all about building momentum during a challenging transition.

So the momentum is built now. The transition roadmap is in place. This is where the power of the first 90 days is!

Wednesday, June 25, 2014

Do you need to be an Influencer to become an Agile Coach?

I had an interesting conversation with one of senior-level executives yesterday. Surprisingly, it was not about agile, it was more about employee potential and how executives evaluate their people. A leader, she said, has to be an "Influencer", and if you are not, we do not see that you're able to lead.

It was an interesting topic for me. First, who is an Influencer? Is it a person who is vocal, highly visible, who knows how to showcase their contribution, who can demand and request, and enjoy being in the spotlight, or something else? Second, can you be successful as an Agile Coach if you are not an Influencer and what qualities do you need to develop to achieve success in this role?

To answer the first question, I checked the "Influencer" description in DISC Profile framework. There, an Influencer is described as convincing, enthusiastic, warm, trusting, and optimistic. Influencers prioritize taking action, collaboration, and expressing enthusiasm. This helped me answer my own question. Personalities differ, and obviously, personalities that similar to ours resonate with us. However, there are multiple ways to influence. People may follow you because they fear your strong negative reaction, because you are so vocal and visible that you become their first choice as a follower, but the moment they are out of your sight or you are out of theirs, they won't follow you, because it is not about values, it is about visual and audio stimuli. Luckily, people are more complex creatures than that. They will follow you if they respect you, if they share your goals, or if they believe in what you do.

And this is how I view my role as an Agile coach. I do not need to put myself in the spotlight to be followed or respected or listened to. Rather, I want to earn this privilege by sharing my values, by being genuinely enthusiastic about what I do, by providing value professionally, and feeling good about what we've jointly achieved. And this is my understanding of an Influencer or leader. If people follow you because they share your beliefs and you share theirs, because they respect you and you respect them, you do not have to be in the spotlight. All you need to do is do what you believe in, tirelessly and enthusiastically, and enjoy every step of this journey.

You won't be successful as an Agile Coach or an Agile transformation leader if you are not an Influencer, but you can influence in your own unique way that motivates people to follow you and respect you, influence by sharing your values and learning about theirs, by leading them and helping them achieve their purpose in the way that resonates with you and with them. And if you have to be visible to create a favorable environment to succeed, then do it. And if you do not, while achieving success and being respected in your role, then you do not have to. My advice is to be genuine and honest, and follow what you believe in, and then others will follow you.

I do not think I am idealistic here. I speak from my experience of an Agile Coach working with multiple outstanding teams and people I've had a privilege of working with throughout my professional life.

And as for that executive in the beginning of this blog posting, obviously, we do not share the same values. Leadership is not the same for everyone.

Sunday, February 23, 2014

Qualities of a Good ScrumMaster

There are multiple descriptions of a ScrumMaster role, my personal favorite being Ken Schwaber's. When I assumed my responsibility of an Agile Coach, I was asked to draft a role description for a ScrumMaster. I used my own experience, multiple scrum sources including The Scrum Guide, and numerous job descriptions I found on the internet. Below (in blue) is the result:

Summary of role: A ScrumMaster is a team leader focused on bringing continuous improvement to the Agile Team and the Agile Community of Knowledge. The ScrumMaster helps the Scrum team and the organization adopt Scrum.  The ScrumMaster is accountable for the ability of the team to deliver the sprint goal / deliverables.  The ScrumMaster is responsible for ensuring that the Scrum team adheres to Scrum values, practices, and rules.
Responsibilities: A ScrumMaster:
1. Creates a motivational, transparent, collaborative, fun, open, and trustful environment where a Scrum team can work efficiently and the business can deliver high-quality products quickly;
2.    Prevents team distractions, identifies and leads the impediments-solving process, and escalates risks and issues if necessary;
3.    Organizes and facilitates (or works with a designated team member to conduct) effective product backlog grooming, sprint and release planning sessions, daily stand-ups, sprint reviews (demos), and retrospectives;
4.    Creates and maintains an electronic repository for the team’s historic information and collaboration space on ongoing topics including but not limited to sprint summaries (demo decks), links to document repositories, impediment log, and the list of retrospective action items and their status;
5.    Garners respect from the team and leads the team towards hyper-productivity; promotes self-management and self-improvement to grow team efficiency and velocity; monitors team’s velocity and suggests corrective actions at a Retrospective, if relevant;
6.    Maintains metrics related to velocity and other metrics as agreed with the product owner and advised by the Agile Coach;
7. Promotes self-organization and cross-functionality within the team; relinquishes command and control style to involve the team in decision making ; promotes effective conflict resolution on the team and outside of the team;
8. Regularly attends and actively contributes to Scrum of Scrums and to the Agile community;
9.    Reports non-resolved impediments to the Impediment Removal Team (IRT) and participates in resolution;
10.  Assists the team in making appropriate commitments and supports the team in standing up for their estimates; responsible for working with the team to ensure that their team is realistic in their commitments;
11.  Creates, updates, and leverages quality information radiators including but not limited to release and sprint burndown charts, task board, working agreement, and other relevant artifacts to create transparency around the team's velocity and progress against its current sprint or release;
12.  Enables the team to focus on high-priority items and increases team accountability for the deliverables by removing impediments, scheduling all ceremonies and facilitating them effectively (or partnering with other team members to ensure effective facilitation), and following up on the action items agreed upon by the team;
13.  Coaches the team on how to be more productive and produce higher quality products by ensuring the health of the process and adhering to Scrum principles;
14.  Facilitates the involvement of shared, fractional, and cross-team resources with the Scrum team; reports cross-team dependencies in a cross-team dependency list and updates the status regularly at Scrum of Scrums and in the appropriate repository; respects other teams and successfully collaborates on shared goals;
15.  Promotes open and transparent communication and alignment with other functional areas, including Finance and Operations; acts as a liaison with other departments within the organization;
16.  Ensures that all deployment activities are in compliance with the established process; and coordinates deployment activities and resources with other teams as applicable;
17.  Helps surface whether the product backlog is not "execution ready" for release planning or sprint planning;
18. Assists the Product Owner with product backlog maintenance and Roadmap creation; ensures that there is a Roadmap and release plan available to every team member.
19.  Leads the Scrum team and its adoption of Scrum by communicating Agile principles and sharing team success in efficient sprint review meetings.
20.  Understands the values, practices, and rules of Scrum and other methodologies and proactively seeks out opportunities to grow this understanding by attending internal and external trainings, reading relevant materials, or achieving professional certifications; educates others on the team and throughout the company; 
Skills: A ScrumMaster:

  1. Is a Hands-on Leader: Garners respect from his/her team and is willing to get their hands dirty to get the job done while staying calm and focused.
  2. Is Communicative and Social: Communicates well with teams and management.
  3. Is Assertive: Ensures Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and authority, make the tough calls.
  4. Is Facilitative: Promotes open communication on the team.
  5. Is Situationally Aware: Is the first to notice differences and issues as they arise and efficiently resolves them.
  6. Is Enthusiastic: Enthusiastic about the deliverables and the process.
  7. Strives for Continuous Improvement: Continually grows one’s craft learning new tools and techniques to manage oneself and a team.
  8. Resolves Conflicts: Able to facilitate discussion and facilitate alternatives or different approaches.
  9. Has an Attitude of Empowerment: Leads a team to self-organization.
  10. Has an Attitude of Transparency: Desires to bring disclosure and transparency to the business about development and grow business trust.
  11. Is solution focused, proactive, collaborative, and intellectually curious about Agile.
  12. Translates technical to business need in demo and translates business need to technologists.
  13. Distills important details of sprint for demo in cooperation with the Product Owner.
  14. Strives to gain subject matter expertise in the products built by the Team.

As you can see, this role description is a combination of ScrumMaster role expectations in Scrum and organization-specific policies and rules, such as information repositories, mandate for having Product Roadmaps, and operational procedures. There are also pain points that are obvious from here, such as Product Backlog quality and residual command-and control management style. 

Let me ask you a question: what do you think is the level of Agile maturity of an organization where this role description has been written?


I bet you guessed right: this description fits well an organization which is in the start of its Agile transition. In this case, it is transitioning from Waterfall to Agile, and it takes time to change organizational culture and people's minds, so everyone is striving for the clear and detailed explanation of their roles and responsibilities.


What is supposed to happen in an organization later, as it moves further towards its Agile maturity, learns how to inspect and adapt, and move beyond every letter of a job description? How is the ScrumMaster role changing at this time?


My hypothesis is that in a mature organization, this detailed description of a ScrumMaster role is no longer needed. What is more needed is the description of inspirational examples of how ScrumMasters resolved a difficult situation or made a difference by suggesting a new process or a creative idea for their teams, how they helped the team members grow professionally and feel heard and respected, and how they helped the team mature in achieving the new horizons in productivity, quality, in becoming successful in working together and being a team. In a mature Agile organization, I would expect a list of bullets to change into a list of "stories" that will guide and inspire many generations of ScrumMasters and Coaches.

Let's write this description together. Please share the stories of ScrumMaster success that will help and inspire others. And I’ll share mine in the Part II of this blog.

Rererences: ScrumMaster Mug image 

Wednesday, December 11, 2013