  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.
0 Comments
 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.  There is an interesting discussion in my linkedin group. The topic is: when you hire a scrum master, do you look for technical skills and leadership skills? Would team members respect a scrum master who is not a good subject matter expert or who is technically challenged? (in case of a software scrum team)
I have seen so many team members who write great code and develop great applications, but fail in scrum master role when they choose to try it out. Similarly, I've see several effective managers totally failing this role because they did not have control over the team any more. So - while I prefer both - I vote for personal skills, leadership, honesty, desire to help, respect, unselfishness. In terms of hiring, there are situational questions that I find most efficient. Here are some examples: 1. An executive walks into your team's retrospective because he wants to know how things are going. Do you ask him out, and how? 2. At a demo, a business stakeholder not directly involved with your product, starts making suggestions like "why don't you change a label of that button" and "I do not like the color of this screen", and does this for each feature your team demo's. The team members look demoralized. How do you protect your team? 3. You are a scrum master for a new team that has no prior scrum experience. At a standup, two team members engage in a 5-minute long conversation on a specific topic. Do you interrupt them at the standup, right after, or wait until the retro? 4. At a retro, your team members do not speak up, while you know that there are communication issues on the team. How do you make them talk? 5. The team committed to 5 stories for this sprint at a sprint planning, but you know for sure they won't be able to complete all of them. How do you tell them about it so that they don't overcommit, and do you have to? There are more complex questions on managing cross-team dependencies, dealing with the business requests to deliver the product by a specific timeline, getting buy-in from the management, dealing with fractional assignments, etc. Any other ideas?  I decided to move this 2013 blog posting to this site because the concept of Lean Startup which was emerging at that time became mainstream in less than two years, but this Lean Startup Machine experience remains a unique opportunity to test your skills and desire to continuously innovate and learn.
The concept of Lean Startup introduced by Erik Ries is an amazing collection of common sense and innovative ideas. If you have not seen his Google talk or read his book on Lean Startup, my advice for you is to stop reading this blog and watch this video instead. My Agile team at work has our own Book Club, and the last three sprints, we are reading Erik Ries' book, and each time we find a lot there to admire, and about as much to disagree with. Some ideas resonate with me (validated learning, minimally viable product, pivoting once your assumptions are invalidated - all makes perfect sense) while selecting a small group of customers to validate your product and make decisions based on this restricted subgroup does not. I value contradictions. Primarily, I do so because I do not believe that they exist. I treat them as puzzles for us to solve. So when I got a qiestion whether I would want to go toLean Startup Machine Training in New York, I said "yes" without hesitation, even though I had no clue what the training is going to be. And once I did, I found that it is all-weekend training which starts on Friday evening and ends of a Sunday evening, and goes almost non-stop for all three days. It is a hackathon-like experience for entrepreneurs and for anyone who wants to learn how to start building your product right. The concept of working through the whole week-end slightly scared me but not enough to pass on this exciting opportunity, so I rolled my sleeves, checked into a hotel in New York and started the 3-day marathon. Now that the second day is over, I want to share my thoughts with you while the experience is still fresh. First, it is worth doing! Learning about lean startup is nothing compared with going through it. Powered by a simple yet powerful product envisioning tool called validation board, my team started with building a fee-free tool for business professionals who need to find company after work hours while on travel (at that time, we were thinking of social activities or just a friendly chat) and after 5 pivots and a lot of interviews of potential customers, we have designed a VIP Travelers Club with a $5K/year membership fees. Interesting that our first idea had a very low conversion rate while the final one brought us an advisor who wants to introduce us to an investor. You never know your customers until you ask them directly! This is my learning experience #1. And the second one is similar: "go out"," "talk to the people". My two teammates - Hao and David - and I spoke a lot to the strangers and learned that the first product that we loved and voted for has limited business value while the final one has a significant business potential. Why am I telling your this? - To encourage you to get out of the building, meet your end user, validate your assumptions and pivot as many times as you need until you find a perfect combination for your Minimally Viable Product (MVP). And once you did, validate and build over again. This is how all successful product owners create their winning products.  Feedback is important for human beings and it is one of the most important means of development. I agree that performance reviews are not the most effective way of obtaining feedback especially in Agile environment where there are a built-in mechanism for feedback, which is a retrospective. Effective retrospectives enforce Agile values and come from your peers. However, I still support all types of thoughtful and one-on-one feedback in a corporate environment because it contributes to the atmosphere of transparency and continuous inspection and adaption, which are important Agile values. There are several drawbacks but they can be mitigated: 1. People do not like to be judged. - Be non-judgmental in your feedback and prepare to take feedback from others constructively and continuously. It feels good once you get into the habit. 2. People are sensitive to feedback. - It is important to create tolerance for risk. If people are comfortable to try, make mistakes, and try again, they need feedback to succeed. Once this understanding becomes your organizational culture, feedback is welcomed rather than causes frustration from the recipient. 3. People get feedback but don't act on it. - Help your colleagues define professional goals that work for them and create such an environment where they will have an opportunity to share their success with others. So my solution to ineffective performance reviews is: decouple performance appraisals from career development and more importantly, from compensation evaluation. Establish continuous feedback flow and a consistent and fair compensation system which does not depend on annual review. Whether it is Google's elaborate promotion system or Valve's "select a peer" system, do not base it on performance reviews. How does it work in Agile? First, we support each other in aligning on our goals. As Netflix refers to it, we are creating a tightly aligned loosely coupled organization. In one of my coaching assignments, we decided to use goal setting process in such a way that scrum masters align in supporting company's business objectives by establishing common goals with their teams. We did brainstorming jointly (of course, we used stickies, silent grouping, and voting) and came up with the following high-level goals: improve accuracy of planning, increase reliability of commit (there were KPIs associated with this to make this goal measurable, differing between teams), building self-organizing teams (this translated into different specific goals for each scrum master), and maturing product backlog quality. Each scrum master has a set of specific measurable (S.M.A.R.T.) goals associated with one of those, and will seek continuous feedback from the team, adjust accordingly, inspect and adapt. How does it all translate to performance appraisals? First, those should not happen once a year, there should be continuous feedback, and all parties should be open to it. Second, it does not have to come from your manager, I think it is important to welcome any feedback you can get and not feel hurt or upset, kind of grow thick skin and take any feedback constructively. Third, think of it as of a way to help you become better, or help your peers become better, not as an input for your salary increase. To sum it up, I agree with Mary Poppendieck that it is important to create an environment where you have a coach, presented with a challenge (Mihaly Csikszentmihalyi's flow), provide and are open to feedback, and foster dedication. How you do it is up to you, but if you find an effective way to incorporate performance reviews in this process, go ahead. Just remember not to be judgmental, rather, use it as a feedback mechanism and as an input to creating goals for your colleagues that will help them become better professionals, better leaders, and better team contributors. |
AuthorTransformation 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. Archives
October 2020
Categories
All
|
RSS Feed