There is a reason educators love playing games. Games promote learning. One-way information sharing is passive and does not stick. According to Michael Schrage, a leading expert on the relationship between technology and work, "the "serious play" that leads to breakthrough innovations is increasingly linked to experiments with models, prototypes, and simulations. As digital technology makes prototyping more cost-effective, serious play will soon lie at the heart of all innovation strategies, influencing how businesses define themselves and their markets."
No surprise that Agile is linked to playing. The creative nature of Agile environment demands active learning and innovation. This is one of the reasons why agilists from around US and many other countries gather annually for the Agile Games conference in Boston, MA. This year I had a privilege speaking at a conference. Actually, not speaking (surprisingly to those of you who are frequent conference attendees, PowerPoint decks and one-way training sessions are not welcome guests at this event) but rather, leading a 1.5 hour-long innovation workshop creating shared learning and ability to take a new look at well-known Agile challenges and resolve them. However, I will write about my presentation separately while this blog is dedicated to my "aha" moments from the conference, which I hope you can apply to your organizations and Agile teams.
I decided to select my ten favorite "aha" moments from the conference:
1. In his outstanding keynote, Thiagi shared many ideas about learning and playing. Check out his web site for a ton of games and organizational change cards. One of his thoughts was that we frequently rush to complete presentation or cover all materials within the time allocated. Don't do it! People remember unfinished business best. Just stop where you are and leave your audience craving for more. This will promote their learning experience.
2. Move around the room as you present. Do not create intense learning vibe in the front of the room where there are no participants. Go around the room and make everyone feel that they are in the front seat.
3. Thiagi taught us many games ideas, and there are even more on his site. Check out this goal setting game or the "35" prioritization game (which was introduced at the conference by Yuval Yeret). My favorite one was writing a topic on cards (one statement per each) and having people walk around the room introducing this topic to each other, and then selecting a winning card. I would use "creative plagiarism", as Thiagi called it, and have participants exchange cards with each iteration.
4. Another great game introduced by Thiagi was to have an SME recite a topic for 3 minutes, and then have teams ask each other 3 closed-ended questions (if the chosen team member answers correctly, the team receive 2 points, another team member - 1 point, otherwise 0) and then 3 open-ended questions (competition between the teams is resolved with voting).
5. Another highlight was the session by Yuval Yeret where he introduced two question/answer tools that can be used for decision-making, knowledge assessment, consensus building, or prioritization. The tools are kahoot.it and socrative.com. Check them out!
6. There were several lego sessions. My favorite was the retrospective session with Ellen Grove and Mike Bowler. We were supposed to build a lego composition that represents our feedback about the conference and share it around the table. There was colorful and creative compositions involved to share many helpful ideas. I am planning to use it at work.
7. The podcast which closed the conference was funny, smart, and thoughtful. It was improvised right in front of us. By the way, there was a great Improv session at a conference led by Todd Charron - I did not have a chance to attend but I heard a lot of laughter from the room that was neighboring with the one where I attended the lego workshop. And it was a great challenge: there were so many interesting choices that selecting a session to attend was super hard.
8. At the second day keynote by Rich Kasperowski, we learned about "modern Agile" which includes open space, besides other items. Open and informal nature of Agile is the heard of success. Rich also taught us how to do a "check in" exercise - we all enjoyed the experience, and even used it in the following session, FeatureBan.
9. FeatureBan lead by Andrea Chiou was fun. We simulated kanban and established experiential WIP limits. Our team, WIPless, increased throughput from 4 to 9 cards in three 10-day games. I also heard a lot about Laura Powers' session about Agile brain and her "Scrum. Or Not?" game from other participants and about David Graver's excellent session. Too bad I was not able to visit all concurrent sessions in parallel!. Meanwhile check Laura's site, http://poweredbyteams.com/. Based on the matchmaking game "Hot or Not" - the game "Scrum or Not" is designed to conclude an introductory scrum training workshop. It gives the group an opportunity to test their knowledge in a fast-paced game where everything is not scrum, but it certainly sounds like it could be.
10. There were many great sessions and learnings at a conference. One of the themes was storytelling. Let me tell you my own "wow" story from the conference. On the first day, I wanted to buy a new book on open space. The books were sold for cash so I decided to withdraw cash from an ATM later and of course, day 2 was so full with great events that I totally forgot. When I realized that I need to buy the book towards the closing session, the book table was already dismantled. I told my neighbor at the table, Mark, that I am so upset that I missed the book, and - what a surprise - I found out that Mark was one of the authors, and he kindly promised to send me the book by mail. What a coincidence! But wait: this is not the end of the story. In the end of the conference, there was a book drawing for five different books, and I won. Can you imagine my feelings when it turned out that I got exactly the Open Space Agility Handbook that I wanted!
Tomorrow is the Open Space which marks the last day of Agile Games 2016. This was a great experience, and I am going back home to start preparing for Agile Games 2017!
It is not news that Agile community is highly inclusive. Agile thinking is formed on collaboration, sharing, and transparency. So no surprise that Agilists love sharing: forums, user groups, meetups, conferences - you name it! I started with answering questions at LinkedIn Forums, then joined a number of meetups and user groups where I met great people who became my friends, mentors, and peers, and then discovered Agile conferences and gatherings. First, I joined as a listener, then was invited to present at one (it was Agile Day NYC in 2012 and then a follow up Agile NYC Presentation- an amazing experience), and then was invited again, then started applying for larger conferences and was invited to speak at some of them (rejected by others), and finally, decided to support one of those where I had a excellent experience as a presenter. Below are my findings and my advice for others who may be in the beginning of this journey.
1. Online Agile presence. As I mentioned, Agile community is super inclusive. Whether you are a starting Agilist or an experienced Enterprise Agile Coach, online communities are a great place for you to gain or share knowledge. I am part of multiple LinkedIn Forums such as this and event post myself.
2. The next steps for me was to attend Agile events. I started with local eventsl: from New York Scrum User Group, Agile NYC meetups, PMI Agile events, other Agile/Scrum meetups in New York and New Jersey. There, I met great people and dedicated Agilists who became my friends and peers over the years. Most of those events are free and highly informative. It is an opportunity to bounce off ideas, get professional advice, meet people who share your professional interests, and share what you have to offer. It energized me because I could support others in the community and learn a lot myself.
3. The natural next step was to host some of those events. It was a great experience. I hosted NY SPIN and PMI Agile Panel at Kaplan Test Prep where I worked at that time, and it allowed Kaplan employees and many people outside of the company to collaborate and shared their experience. I did not mention yet that all of those were free events (some of those may charge $5-$6 for pizza and drinks provided there because people come after work day and it is an opportunity to share professional interests in a warm home-like atmosphere). They are run by community enthusiasts who do not get paid or rewarded anyhow else but by communication and collaboration. Up until recently, I have not heard of a presenter (even well-known) ever paid for presenting at a meetup. I was sad to hear of a first instance recently and I truly hope it's an outlier. The one below is free of charge and open to everyone - feel free to join!
4. After these first successful hosting experiences, my colleagues and I co-organized our own Agile/Lean Practitioners Meetup at Kaplan Test Prep which is now in its fifth year of existence and unites 1,259 practitioners as of today. Recently, Jeff Sutherland presented at our meetup - my posting on this is is on my blog. But most importantly, over a few years it became an important destination for the tri-state Agile community and a great venue for sharing Agile and Lean experiences. This is where I presented on Agile topics for the first time for the external audience, and it was a professionally rewarding and encouraging experience.
5. The next step was organic: my colleague and I were invited to present at Agile Day NYC 2012, and the experience was overwhelming. The feedback from the audience and from several well-known agilists who were at the event was energizing and though provoking. This is where I realized that sharing your thoughts with a large audience gives you an opportunity to organize your thinking, to meet amazing people, and get the feedback that you cannot compare with individual learning. This is how my speaking journey has begun.
6. Last year, I presented at Big Apple Scrum Day (BASD). The topic was "Agile Coaching is Dead. Long Live Agile Practicing." I was concerned about the provocative nature of my title and wanted to hear from the audience how they feel about my take on Agile Coaching changing as a profession over the last few years. The audience was amazing. Despite the large number of participants, we had a dialog, and it was positive (despite the difference of opinions) and I learned a lot from the conversation (and so did the participants). I came home energized and excited. When I came to Agile Day NYC in the fall, it was great to see many BASD participants and exchange our latest news and get their advice and encouragement.
7. Then, a friend of mine, Dana Pylayeva (who I met through an introduction in her role as a BASD Conference Chair) suggested that I apply to speak at larger conferences, and I submitted my topics to the Agile Games, Global Scrum Gathering, and Agile Conference 2016. I was selected by Agile Games, and I am excited to present in Boston in April 2016. Will share this experience with you in my upcoming blog postings. Thank you for your encouragement, Dana! I don't think I would have courage if Shilpa did not introduce us and you shared your passion as an engaging and thoughtful conference speaker. But things happen for a reason, and I was ready for the next step.
8. Excited by the community and the experience, I volunteered to support Dana and the New York Scrum User Group community for BASD-2016, a non-profit Agile community conference. Until you participate in organizing one of those events, it is hard to see the amount of work that goes into those. Just some of the activities include finding and booking a venue that can hold 300 people (talk to me if you think it's an easy task in New York), setting up an engine to collect submissions, then forming and running a team of expert Agilists who will be selecting out of hundreds of great applications, tying it all into a cohesive agenda with parallel sessions, organizing the space and food so that every participant feels comfortable, enjoys the food and the experience, and then make everyone feel welcome while providing an encouraging venue for ideas sharing and making it both interactive and a deep learning experience for everyone.
All the people who participate in organizing those events do it in their "free" time after work and do not get any remuneration, except for the opportunity to contribute to this community. When I asked Dana why she is doing this, she shared that she felt as a long-time conference presenter that she wanted to give back to the community, and this is why she organized BASD, which is a huge success in its second year of existence (all tickets are sold out 5 weeks before the May 16th event). By the way, it's not too late to be a volunteer.
The reason I am sharing my journey from being an observer to participant to host to organizer is to encourage you to think where you are in this journey and where you want to be, and if you are looking for encouragement and advice in this journey, feel free to reach out - I'll walk it with you.
Today, Jeff Sutherland presented at Agile/Lean Practitioners meetup at Kaplan. It was a big event with over 100 participants from multiple meetups and a lot of practitioners and agile coaches. The conversation was about benefits of Scrum, and while it addressed a well known topic, it was a great refresher of Scrum non-negotiables and a reminder to the audience, as Jeff described it. The primary focus of the conversation was productivity, both sides of it: what increases productivity and what kills it.
I was not taking any notes but as I was listening to the presentation which included well known facts presented in a metrics-driven way with a good sense of humor, I was thinking through my current and previous experiences and trying to figure out whether we are following those practices or deviating without realizing it. Below are the ones that caught my attention:
1. Multitasking. Everyone knows that multitasking results in loss of productivity. I knew the context switching results in 20% productivity loss. What I did not know was that this metrics is related to context switching between 2 items. Once you get to 5, your productivity loss is 75%. This is a powerful proof of WIP, limiting work in process.
2. Happiness. When Jeff was talking about the concept of company success, he started with employee success, which provides immediately impact on company performance. According to Jeff, there is proven direct correlation. Happy employees - happy company. There is a direct dependency between RoI and level of happiness. His advice is: measure your employee happiness every sprint and pivot if needed.
3. Cross-functional teams. If we want to succeed, we form a cross-functional team. There may be specialists on it, but no one is exclusive and everyone can do job(s) of others. According to Jeff, a lean implementation will not be successful without a cross-functional or cross-trained team.
4. Swarming. Interestingly, the scrum framework has been patented under the word "swarming". Swarming is the heart of Agile. By swarming, Agile teams achieve shared objectives. Jeff sees swarming as the core concept in Scrum.
5. Kill impediments - Jeff's advice is to use "no prisoners" rule and kill impediments as they arise, no matter how complex or easy they are. Impediments should not be ever kept in the backlog for over 24 hours.
6. According to Jeff, all these rules similarly apply to software or non-software teams, this distinction is purely semantical from methodology perspective. Non-software team's agile is as basic and as important as a software team's.
These are the ones that resonated with me. Overall, there was a lot of helpful metrics and insights on productivity increase, lean principles, and kaizen thinking. A helpful concept that came up was the discipline within Scrum. As we know Scrum does not mean ad hoc, it brings transparency and cadence of execution. The example that Jeff provided was a CMMI5 company in Europe which increased productivity 5 times and reduced waste from 64% to 9% by moving to Scrum. Very impressive!
In sum, great points by Jeff. We all know them but frequently overlook, myself included. Let's stick to those because we know they work!
On November 3rd, The Agile Group of Project Management Institute’s New York City Chapter, invited me to speak to their members about Agile implementation at scale. It was an interesting opportunity to learn what the major challenges of Agile implementations from a project management perspective are and to share the patterns that make an Agile transformation at scale a success.
Leo Tolstoy’s book Anna Karenina begins:
"Happy families are all alike; every unhappy family is unhappy in its own way."
We can refer to it as the "Anna Karenina Principle" which is fully applicable to implementing Agile at scale. Imagine, you rolled out Agile in your organization successfully and your energized teams are delivering high quality software on cadence. What does management say next? Let’s scale! You coach more, establish repeatable practices, coach the teams, but all of a sudden, it all falls apart. Unmanaged dependencies, overlapping product backlogs, conflicting roadmaps which bring quality issues, delays in delivery, frustrated teams, and unhappy stakeholders.
Scaling Agile is still a hot topic years after the first failed attempts of Agile implementation at an enterprise level. There are many successful examples of scaling Agile at a significant scale. Between multiple scaling models (SAFe, DAD, LeSS) there is something in common that makes or breaks it. Remember the Anna Karenina Principle? "All happy Agile implementations at scale are alike; all unhappy implementations are different." The goal of my presentation was to offer practical advice for organizations that want to follow the pattern of "happy" implementations of Agile at scale.
The audience asked a ton of questions about each of the patterns presented. Project and program managers and directors of Project Management organizations wanted to know about Acceptance Test Driven Development (ATDD), program management in Agile, culture and resistance, the role of middle management in Agile, and multiple other practical topics of Agile implementations. It was a great sharing opportunity and a way to contribute to community knowledge.
You can find my deck from the presentation on slideshare.
Have you ever dealt with a skeptic in your organization who does not think that scrum masters bring value to the team? Who thinks that all that scrum masters should do is schedule and facilitate ceremonies, and everything else that scrum masters do - removing impediments, protecting the team from distractions, improving the process - the members of cross-functional teams would do without any problem. He views scrum masters as creating more work for team members in order to justify their own existence.
I know this is not the case. Without the scrum masters, team members will have to spend hours removing impediments, fighting with external distractions, and implementing improved processes on their teams. However, this is hard to quantify, unless we remove a scrum master from a team and measure their productivity before and after. But if we don't want to be that radical, what can we do?
The more I have been thinking about it and trying to quantify Scrum Master value, the more I realized that the best scrum masters are not those who are highly visible and vocal but those who are most supportive of their teams, who encourage continuous improvement, and make their contribution to the team almost seamless. This is similar to the race car mechanic who's not visible during the race but plays crucial role in the team success.
This thought did not help me with coming up with the proof of the Scrum Master value and an explanation that it won't be right to have team members protect themselves or remove impediments, such as coordination of development and deployment activities with other teams, changing priorities, and changes in team composition. So I posted the question onlinkedin forum for certified scrum masters (got several great ideas and a lot of encouragement) and did some research. What I found is fascinating! I truly believe that this is what defines a great Scrum Master:
Tao Te Ching Written by Lao-tzu Ch 17
When the Master governs, the people are hardly aware that he exists.
Next best is a leader who is loved. Next, one who is feared. The worst is one who is despised.
If you don't trust the people, you make them untrustworthy. The Master doesn't talk, he acts.
When his work is done, the people say, "Amazing: we did it, all by ourselves!"
Credit goes to Jeff O.
While this is so true, it is hard to prove the value of something that is not always visible and never is obvious. To understand the value that scrum master brings to the team, a good starting point is the checklist of things the ScrumMaster can look at and work on. Michael James from Danube has an excellent Scrum Master Checklist available for download. Another great Scrum Master checklist was put together by Bernd Schiffer who citesScrum Master manifesto in response to a common misconception that Scrum Master is not a full-time job: "We believe the Scrum Master is a full-time position for one person on one Scrum team ."
I would argue that the team won't achieve hyperproductivity without a scrum masters described in this checklist whose value is well defined by Bob Hartman. Both Bob Hartman and Michael James speak of intangible things - influence, sense of purpose, commitment - which translate into tangible outcomes which can be measured. Similarly, Len Lagestee speaks of "transformational leadership" - the role that scrum masters play on their teams supporting their path to greatness and about a leadership code of a Scrum Master.
This type of value is not easy to quantify. I like comparison of a scrum master with a football coach standing on the side-lines during the game. A football coach doesn’t play a position but they are constantly looking at how the team are interacting with each other. They know if the defensive line is being held too high and how the team aren’t working together to achieve a common vision. After the game the coach helps the team look at their performance for strengths and weaknesses, they’ll identify actions for potential changes and implement them incrementally. Although a football team may be able to play one or two games without a coach, other teams will eventually overtake them in ability and effectiveness.
This is not a question that has an easy answer. Working with multiple clients, I got multiple requests to hire Scrum Masters who can code in Java or to explain Agile to a Tech Lead in one day so that he add responsibilities of a Scrum Master to his technical and managerial duties. This will keep happening and Scrum Master responsibilities will continue to be questioned, but this situation will also produce amazing leaders who do not concentrate on titles and who are organic leaders - and servants - on their teams and organizations.
An exciting experience presenting at Big Apple Scrum Day 2015 and a great discussion about the future of Agile coaching as a profession. The full deck is posted here.
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!
What can you use Agile and Lean for? Software delivery? Manufacturing? My answer: everything! Even running a company.
Let’s first consider the value. For me, as an Agile Coach and practitioner for many years, there are three things that make any Agile team successful:
As simple as it sounds, this is not easy to achieve: a team is going through multiple phases before it becomes high performing. A backlog is a product of multiple conflicting priorities and ambiguous features, and the cadence is frequently impacted by multiple emergencies and schedule changes. Yet, without all three components it is impossible to achieve an established velocity or high productivity.
In one of my engagements when I led an Operations team, I saw my role in leading and supporting the team in establishing our operational rhythm based on all three Agile components of success listed above, and this is how we do it:
1. Collaborative cross-functional team. Culture comes before everything else. It has been proven time and again that collaborative well balanced teams achieve success in every single area they choose, while a collection of brilliant misaligned individuals moving in opposite directions rarely is capable of accomplishing anything significant.
Everyone on the operations team was supportive and ready to swarm on high priority items no matter if they fall within their immediate area of accountability. How did we achieve that?
Step 1: We create a cross-functional epic to achieve any strategic goals, whether it is a new on boarding process for our consultants, or a company Meetup for our engineers - open to any technologists who would like to join us.
Step 2: For each cross-functional epic, everyone creates stories and tasks related to their functional area of contribution – for example, for the Meetup, our talent development team, CTO, marketing – everyone collaborates to make these workshops successful and informative for engineers.
2. Now the second component of Agile success: a healthy backlog. We have weekly sprints so our backlog is never stale. We do ongoing grooming during the sprint and we use persistent chat to discuss any questions related to priorities and time lines. When we need input from the team, we create tasks for our team members. Just-in-time tasking helps us stay current. The challenge of just-in-time tasking is to ensure there is a handshake and an agreed upon time line between the team members, so that the scope does not increase during the sprint. Our Agile tool, Jira, is a helpful mechanism of organizing our backlog and reflecting planning results in a prioritized and structured form.
3. The third component is the well-established cadence, or our operational rhythm. In order to stay in rhythm, we needed to define whether release planning applies to an operations team and whether sprint cadence works for us better than kanban, which is traditionally suitable for operations. We discussed our cadence at the latest retrospective, and decided to leave the rhythm of quarterly strategic planning, monthly release planning, and weekly sprint review and planning sessions, in addition to the daily stand up. We are still finalizing the format for each of these ceremonies.
What is my role on this team? Probably you’ve guessed already. As a team member responsible for running smooth operations, I act as a Scrum Master. No more status meetings or progress updates. Collaboration, alignment, open mindedness – these are all signs of a productive team. Our burndown chart and sprint commitment rate (the ratio of completed work to committed work within the sprint) are the best indicators of the predictability and quality of planning.
About lean: Continuous improvement is the heart of our Agile implementation. At every retrospective we come up with more ideas for how to optimize our processes, make them repeatable by creating checklists and templates, utilize modern tools such as online checklists or new Jira functionality – whatever it is, we are eager to try and learn. Once one of us comes up with an idea, the team discusses it and everyone is positive, open minded, and ready to try it out. If it works, we make it part of the process, if it does not, we pivot.
We do not wait for retrospectives to improve our processes. We try to come up with one improvement a day – whether it is installing chrome boxes in our conference rooms or turning one of the conference rooms into a cozy library full of technical and professional growth books. There are small ones, such as switching from a phone call to Google hangouts for our stand ups – but whatever they are, everyone feels ownership and support in introducing our “2-second improvements” every day.
There is a lot more I can tell you about how exciting Agile journey is for our team, but I do not want to give you impression that everything is perfect. We are on our journey to fine tune our rhythms and working towards commitment rate of 90%. Predictability of delivery is very important to us because our clients and consultants depend on how efficient and responsive we are on the operations side, so predictable and efficient operations are our utmost priority.
No one needs to prove that Agile is a modern delivery framework. According to VersionOne’s State of Agile Survey for 2015, 94% of all organizations surveyed are practicing Agile. In addition, 45% of respondents worked in development organizations where the majority of their teams are Agile. Contrast this with the 2009 report: only 31% of the respondents worked in organizations with zero to two teams practicing agile. There are multiple successful Agile implementations with well documented case studies around them.
We cannot state the same about scaling Agile. There are several frameworks: Disciplined Agile Delivery by Scott Ambler, Scaled Agile Framework (SAFe) by Dean Leffingwell, and Large Scale Scrum (LeSS) by Craig Larman. Introduced by three different thought leaders, each framework generated communities of practice and a number of positive stories related to successful implementations. That being said, each of those frameworks requires deep analysis and experience in scaling Agile in order to be successful. Frameworks define the approach and the implementation paradigm, but in each case it is the methodology built on top of those frameworks and the company-specific execution that makes or breaks it.
At InRhythm, we have been providing enterprise level Agile support for almost 10 years, and we have our own defined methodology. When SAFe was introduced, we felt that our experience and approach resonated with the crispness and the combination of Agile and Lean practices defined by SAFe. Our current approach to supporting large organizations in scaling their Agile delivery is based on three steps:
How did this collaboration happen?
Our company's goal is to bring thought leadership to our clients and support change within their organizations. The clients who bring us in are the leaders within their organizations. We come in as change agents to support their commitment to continuous improvement. This is how this company, via a prior client referral, brought us in to support their commitment to scaling Agile.
Initially, a team of Agile coaches came on site to meet with their executives, team members, as well as product and delivery managers. The team attended their Agile ceremonies, reviewed artifacts, and mapped their delivery processes. Their receptivity to change, open thinking, and positive attitude still resonate with me. I felt proud to have had a chance to collaborate with such a strong leadership team. We were able to identify their areas of strengths, which they could build upon, as well as provide practical advice on areas of opportunity that, if addressed, will expedite delivery and support quality at the portfolio level. Based on our findings, we created a customized training curriculum to provide specific implementation details to the teams within a large portfolio.
Once this was shared and presented to the client, we were excited to head back on site and provide the training, which we certified with the Scaled Agile Academy. The training covered how a large software delivery structure should be organized, how to manage dependencies, how to identify priorities at release level, how to build program-level engineering practices, and several practical details of scaled Agile implementation. In addition, we discussed how each of those principles applied to their specific organization:
The next step includes coaching Agile implementation teams at the portfolio and program levels, co-create artifacts that reflect their unique objectives and organizational structure, and provide thought leadership in building repeatable processes that will stay with the organization after we leave. It is such a great responsibility, and so much fun, to help organizations build world-class practices and sustainable cultures of Agile delivery at scale!
This is my older blog post from 2012 when PMI-ACP exam was introduced. Being part of the pilot group, I enjoyed the opportunity to "test the test" and contribute to how this PMI examination shaped up. I'm hearing that it has not changed much, and many people who still read this blog post reach out to thank me for this information or share their experience. As a result, I decided to move this post to this new site, hoping that it may be helpful to some of our visitors.
In today's competitive job market, primary credentialing is an important way to identify industry professionals with a full understanding and practical experience. It also a way for employers to identify prospective employees with valuable industry experience which is confirmed and verified by the means of widely accredited and recognized certification.
This is one of the reasons the new PMI-ACP examination (http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx) released in 2011 raised significant interest in Agile community world-wide. As of December 2011, the following numbers on PMI-ACP examination were available on PMI community blog page and some other sources (http://agile.vc.pmi.org/Public/Community/Discussions/tabid/170/aft/9709/Default.aspx,http://thecriticalpath.info/2011/12/13/pmi-acp-numbers/)
My pilot experience is not fully relevant anymore. But here it is:
I took PMI-ACP exam in November 2011 and I feel it has been a rewarding experience, which I am happy to share with you. First, I want to share that I embraced the fact that PMI acknowledged Agile by instituting this certification and while I’ve heard a lot of contradictory opinions on this subject, I felt that this exam is a bridge which will fill the gap between Agile and what we call “traditional project management”. PMI-ACP certification exam was welcome by the Agile community.
Overall, this exam is an remarkable step towards bridging traditional, waterfall project management and adoption of agile practices. Many organizations in multiple industries are adopting agile practices to align their development environment to changing market needs, and with this trend, the requirement for project managers trained in agile practices is going up. In January 2010, Forrester release a research which shows that 35 percent of 1,300 respondents stated that agile most closely reflects their development process and made a conclusion that agile software development processes, in which software is built in short iterations rather than mapped out fully in advance, have joined the mainstream of development approaches(http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2).
The new PMI Agile-Certified Practitioner certification, PMI-ACP, reflects this tendency and addresses the requirement from project management everyday reality. Being an established project manegement boady with high value for the certifications it awards, PMI made this step towards recognizing the value of Agile practices. PMI established its Agile Community of Practice in 2009 and PMBOK® Guide 3rd & 4th edition contain references to iterative development. According to PMI,
For practitioners, PMI-ACPSM helps:
While I was excited about taking the exam, I was concerned with the fact that the questions and expected answers from PMI should not violate Agile values and principles. The concerns were triggered by two facts: first, PMI was not involved as an organization (according to my knowledge) in building Agile repository of knowledge so it is acquired methology rather than conceived and lived through; and second, since there is no AgileBoK (at least no single repository of knowledge on Agile), I was concerned about the level of consistency between 11 books suggested by PMI for preparation to this test.
Based on my exam experience, neither concern is in fact a concern for Agile community. I think questions adequately reflect Agile values (I am not aware who exactly was involved in creating the questions, but I certainly feel that exam preparers are Agile practitioners who share Agile values). And while there is certain degree of inconsistency (most obvious one is “Agile project manager”, “project leader”, and “scrum master”; or “team” refers to both “scrum master” vs. “team” and “scrum master and development team” in different questions – you would have to guess what is applicable) but overall, I did not come across significant inconsistency or ambiguity.
Overall, the exam experience was pleasant. I completed the questions in 1.5 hours and took another 30 minutes to go through those 20 questions out of 200 that I was not sure about. But let this not misguide you. This does not mean that exam is easy, though about 60% of the questions were quite straightforward, if you have significant Agile experience and have read the books from the list. You may not need all this time because there are no complex formulas or tricky confusing questions, but the level of knowledge required is adequate. It was not as difficult as PMP exam for me, which required a lot of preparation, but luckily, I’ve read most books on PMO list before PMI-ACP exam was introduced, so my preparation was reasonable. Again, it is hard for me to judge because I do not know the result yet – the results will be made available in early January (originally, it was reported to be Q4, 2011). While everyone would love to see results immediately after taking the test, I understand the reason why this is delayed and the fact that baseline has to be established before providing assessment. I find it thoughtful and support this decision by PMI, though I’ve read a lot from the disappointed test takers who were unhappy that they did not see the results right away. Pilot is a pilot though, and it will establish baseline for future test-takers.
Please note that PMI-ACP is not the only exam in the field of Agile knowledge. Scrum Alliance transformed the Certified Scrum Professional (CSP) program starting January 2012 by offering a 150-question exam, which is available at proctored test sites around the world and has a three-hour time limit (http://www.scrumalliance.org/pages/certified_scrum_professional). The intent behind the CSP certification program is to offer a clearly defined and well-respected credential in the Agile community, recognized as the primary credential for Scrum Professionals and sought by the employers who hire them. The beta test that was conducted in October 2011 to assure that the CSP examination met accreditation requirements and is theoretically and technically sound, and as of January 1, 2012, Scrum Alliance will be offering CSP as a credential that implies, regardless of the Scrum role in which an individual works, those holding it have a full understanding of Scrum and its implementation.
This being said, CSP certification deserves to be a subject of a separate review, and back to PMI-ACP exam. For those of you who are planning to take the exam, below is my summary from the test I took in November 2011. While it would be unethical to list specific questions, I will list the areas and my not-so-accurate and definitely subjective estimation of the exam topics and what to pay attention to while preparing for the exam:
1. Risk Management in Agile – around 10% of questions. This was not an unexpected topic (I read on linkedin that this area will be significantly covered but I was not prepared for the depth of questions asked). Make sure you understand risk burndown chart, have an idea on how Pareto principle applies to risk analysis, and how risks are managed in Agile vs. waterfall.
2. How Agile delivers business value – around 10%. There were multiple well versed questions on the topic, many related to Lean but some to scrum (hopefully you understand the term “empirical process control” described by Ken Schwaber in “Agile project management with Scrum”). However, in some questions, the concept of business value (or “customer value” – these terms seemed to be used interchangeably) was hidden. Overall, there were multiple concepts tested, such as incremental delivery, time to market, and minimal marketable feature. Separate topic – EVM and measurements around customer value. If you read “The Software Project Manager’s Bridge to Agility”, you got this covered.
3. Agile values and principles - around 10%, according to my estimation, but these are difficult to estimate because all test questions relate to them and most were tested indirectly, e.g. the concept of sustainable pace or self-organizing team, however, there were direct questions on literal verbiage of those.
4. Estimation and planning – largest group of questions, around 15%. Techniques – be prepared for terms like “Dephi technique” or “Monte Carlo analysis” – but if you passed PMP exam, you are most likely very comfortable with this terminology. Other questions were well thought-through questions related to who estimates and what unit of measurement is used with 2 or 3 specific examples where you will be asked to do iteration breakdown. Be familiar with the concept of progressive estimation. Overall, if you are practicing Agile and understand abstract nature of story points and the concept of velocity – and if you read Mike Cohn - you should have no problem with this large group of questions.
5. Agile methodologies and relationship between them – another 15% or so. I had 5 or 6 questions related to Lean, one related to WIP in Kanban (very basic), and quite a few XP questions – on roles, principles, concepts. Interestingly, there were questions about relationships between those (scrum and XP or waterfall as opposed to Agile). Questions were not overly deep or difficult, but some were quite specific to the term or the concept.
6. Roles in Agile – 10%. Multiple questions on roles – roles in Agile in general, in Scrum, in XP – roles related to specific ceremonies or artifacts, such as the “Definition of Done”. About 6 or 7 situational questions asking who is responsible for a specific artifact or who should take action in a specific situation. You should understand well when self-organizing team takes lead, and when scrum master is supposed to interfere to preserve process health – some questions seemed to be tricky – or maybe just deep and thoughtful. Pay special attention to roles in XP – there was a question about those which would be tricky, if you expected a scrum master to be one of XP roles.
7. Behaviors and cultures – no less than 10%. I want to applaud PMI for having those questions. They relate to culture of transformation from waterfall to Agile, conflict resolution, proper behaviors in unwanted situations. I have to confess that I haven’t read Lissa Adkins’ book “Coaching Agile Teams” as part of my previous Agile life, but I read it in preparation for the exam and found it very helpful and informative. Highly suggest that you cover this material in preparation for the exam.
8. Agile/scrum artifacts and ceremonies – another 10%. Multiple questions on burndown chart (including a practical question with a sample), two questions on information radiators, and – surprisingly – no single question on story (task) board – maybe I was just unlucky and did not get one picked. Multiple questions related to all Agile ceremonies – what questions are being answered, what’s the purpose and structure/duration, who participates, how is process enforced. If you read Ken Schwaber’s “Agile Project Management with Scrum” and if you are a Scrum practitioner – no need to worry, they are mostly intuitive.
9. Resources – about 5% – multiple resourcing concepts related to team composition, dynamics, colocation. Good questions provoking thinking – just one advice: be familiar with the concept of fractional assignments. I personally find it useful and was pleasantly surprised to see it on the exam.
10. Communications – also around 5% - questions related to importance of face-to-face communication in Agile and techniques of working with distributed teams. You would have to understand the concept of “osmotic communication” – almost everyone who writes about the exam indicates surprise that this not-so-widely-used term appeared on the exam – however, I agree with the choice of exam preparers because it is an important concept and one of success factors for Agile implementations.
My advice on books:
All the books listed by PMI is a cerefully made selection of the highly informative sources on Agile and it is important to read the all. Here are some sections to pay particular attention to:
· From James Shore book, read about "fractional assignment", what they are, and whether it is advisable to have those in Agile.
· Read Mike Cohn (both) and Alistair Cockburn - cover to cover on estimating and planning.
· Michele Sliger - on risk management and EVM.
· Lyssa Adkins and Ken Schwaber - make sure to remember specific examples because there are similar behavioral/situational questions on the exam.
· Alan Shalloway et al. - on value stream management.
I read all books in my preparation for the exam, and as challenging as it was, it was a great experience to read and re-read them, and each one of them is a great book - informative and interesting.
And finally, if you are interested in expanding your Agile horizons, I want to add several books to PMI list that you will no doubt enjoy as much as I did (but most likely you’ve read them already):
· “Scaling Software with Agility: Best Practices for Large Enterprises” by Dean Leffingwell
· “Scrum from the Trenches” by Henrik Kniberg
· “Management 3.0. Leading Agile Development. Leading Agile Developers, Developing Leaders” by Jurgen Apello
· “Agile Portfolio Management” by Jochen Krebs
· “A Practical Guide to Distributed Scrum” by Elizabeth Woodward, Steffan Surdek, Matthew Ganis
· “Practices for Scaling Lean & Agile Development: Large Multisite and Offshore Product Development with Large-Scale Scrum” by Craig Larman, Bas Vodde
Everything you’ve read above are my personal impressions from one instance of PMI-ACP test-taking based on my personal experience and perceptions. While I hope this will help future PMI-ACP test takers, please be aware that you will get a different set of questions/topics on your exam. Also, our level of experience may be different, so the items that seems either basic or complex to me, may be something different for you. My opinion is based on 6+ years of experience as an Agile practitioner in a scrum master as well as agile coach and transofrmation specialist role, prior PMP certified project management experience, as well as the books I read from the PMI list and beyond on the topic. As I mentioned, I am a member of PMI as well as Scrum Alliance and hold both PMP and CSM certifications. This review is independent and has not been reviewed or entitled either by any of those organizations, or by my employer.
I wish you all a successful exam taking experience.
Transformation agent with experience in business transformation including transition to Agile (Scrum, kanban, lean) and building scaled Agile and Lean organizations. Passionate about motivating people and building great teams.