I was recently asked what to do when a stakeholder or client asks for a feature or user story that either doesn’t make sense or is based on flawed logic or on a lack of technology or domain knowledge. Sometimes stakeholders’ pet projects, wacky ideas and whims and fancies can be the nemesis of a product owner and her team. They waste valuable time and resources and in some cases they can affect team morale, as the team feels that they are on a fruitless errand.
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
I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.
As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to 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
I am often asked this when delivering training on writing requirements. The most obvious difference is semantics. A user story is generally written as a statement of something a user wants to do with a system and for what purpose. For example:
I want to find clothing that is my size.
While a requirement statement is traditionally written in a more formal style, starting with “The system shall” 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