A PMP® and a Scrum Master® were having lunch together on a park bench debating the relative merits of Agile as opposed to traditional waterfall project management. They were making the arguments one would normally expect. At one point, the traditional PMP felt the need to prove his devotion to his profession by pulling out his wallet to show the Scrum Master his PMI membership card. As luck would have it, a thief was passing by and, seeing his opportunity, snatched the wallet and ran off.
Expert Opinions Vary
While attending the Agile 2015 conference in August, I heard a lot of discussion about pure agile teams, waterfall teams, and a combination of the two. A number of the presenters stressed the importance of being a 100 percent dedicated agile team. They stated that the only way to be successful is to make sure your team or company follows the Scrum/Kanban/XP/etc. methodology in its purest form. Other presenters called out these statements as false and went on to discuss numerous examples of blended approaches that have worked at their company or with their clients. How can an organization trying to understand agile figure out the best approach when so many experts in the field have different opinions?
It begs the question “Why do these organizations want to adopt Scrum”? Adopting Scrum does not mean that those formerly known as Project Managers are out of a job. The job just becomes different. The project world by definition is temporary. Every project has a start and end.
There has been a significant amount of discussion regarding the tension between development and agile contracts. Many see this conflict as irreconcilable, citing provisions in the Agile Manifesto favoring “working software over comprehensive documentation” and “customer collaboration over contract negotiation.”
Those who see the conflict this way claim that lawyers are operating in an outmoded mindset and need to be educated about the agile method of doing business. These same people claim that lawyers perceive many agile practitioners as unrealistic and naive.
In my view, this so-called tension is the result of a misconception of the lawyer’s role and of his or her duty to the client.
Most agile approaches don’t include the role of the business analyst (BA) or even discuss any analysis work. Analysis is the process of understanding needs, finding the root cause of problems, and brainstorming about the best solutions. This is a critical-thinking process that considers impacts and ramifications before acting. And this is the expertise of a business analyst.
Reluctant Business Analyst Using Agile
I enjoyed the Business Analyst World Conference in Atlanta last month and presented “Confessions of a Reluctant Agilist” to a group of Business Analysts. I asked everyone to write down one reason they are reluctant to use agile approaches, and then encouraged the attendees to be more open about the possibilities for success using these new approaches. It’s interesting to see where the reluctance is coming from. Much of it seems to be related to myths about agile rather than facts. Here are some of the reasons reported.
Innovation versus Renovation in Product Development
Getting product development right is often a rare combination of innovation, creative process, critical thinking, market awareness, and discipline. Product development addressing new needs and markets is best done in an evolutionary manner—in incremental steps that work with proven technologies. If done right, product innovation can be very rewarding but always includes some measure of risk. Building on proven products and technologies can help mitigate some of that risk.
Servant leadership is one of the critical success factors in agile approaches to product development. The behaviors associated with servant leadership are not new, but they are very difficult to implement. One aspect of servant leadership is the ability to allow team members to choose their own work and get it done using their own approach. Many managers feel that letting a team “self-organize” or “self-manage” is pretty risky. As a manager, when I first read about the benefits of a “self-directing” team, it sounded like a great idea. But when I had to step back and let my team figure how to get things done on their own, it took great discipline.