I’m going to make a bit of a radical proposal here. I propose that we add the following to the Agile Manifesto:
We value interpersonal skills over technical knowledge
I’m not really proposing that we change the manifesto. I’m also not stating that technical knowledge is not extremely important. Remember that the Agile Manifesto states that we value the things on the left more than the right, but we still value the things on the right. I’m just making a point that I think a lot of organizations miss that affects their ability to really get the most out of Agile and Scrum.
One of the most common myths about Agile and Scrum is that it’s something that only affects the developers. People, in particular executives and directors, believe that undertaking an Agile transformation means project teams change the way they work together and the rest of the organization just reaps the benefits. While this may be true in the short term, it’s often leadership and management that have to make the biggest changes for Scrum to be successful.
I was inspired to write this post after a chat with a friend who works in an organization that has been using Scrum for a few years. He told me that it didn’t take long for the weaker leaders to struggle as the organization adopted Scrum. He also said that the changes to how teams worked and were led created natural leaders who stepped forward and took the reins, sometimes even people no one expected.
I’m going to explain this with a rather facile example. Continue reading
A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.
Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading
Most of you have probably seen this meme on Facebook, Twitter and elsewhere. Generally it is an image, probably taken out of context, of someone demonstrating a lack of understanding, with a comment to the gist of “You’re doing it wrong.” While these images are a little extreme, I’m sometimes reminded of them when consulting on requirements analysis. I’m not saying that organizations are often completely missing the boat, but I’m pretty sure that if they stepped back a bit they’d quickly see their problems for themselves.
Before I start with my first topic in this series, I’d like to quote the IIBA‘s Continue reading
Test Driven Development (TDD) turns the process of writing code and designing systems around, having developers create an automated test or tests before making any changes to the system at all. If the system then fails the test, the developer makes only the changes necessary for it to pass the test, including possibly refactoring the code or addressing the design if necessary. Then the developer reruns the test.
There are many benefits to this practice. First, Continue reading
Lack of stakeholder and user involvement is often cited as a primary reason for project failure and the greatest source of project risk. Unfortunately, whether you adhere to an Agile, traditional, hybrid or mixed methology, getting and keeping customers involved in the development process is always a challenge. I explained previously that the most common reasons customers state for not being involved are that they are too busy, they don’t trust the technical team’s ability to deliver, and that they don’t see the meetings as productive.
The first reason is generally beyond a project manager’s control, and the second is a lack of trust between stakeholders and IT that is often Continue reading
In my last post I described 3 reasons customers cite for not participating in development. One of the reasons, and one that a project manager or business analyst can impact directly, is the customers feel that the meetings are not a productive use of their time. They feel the meetings don’t accomplish anything, take too long, or that they were unable to contribute and their presence wasn’t necessary.
I’ve witnessed many meetings with customers that I would describe as dysfunctional, and I’ve worked in many organizations where meetings with no agenda, no direction and unclear outcomes are the accepted norm. The focus Continue reading
Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:
“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”
This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:
“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”
I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto: Continue reading