Everything I needed to know about development ...
I believe there are six principles that govern solution delivery and for the sake of this discussion software delivery. Simply stated:- We get paid when we deliver something that our customers will buy
- We stay in business when the customers pay more than we spend.
- Define and Own the Problem
- Follow the Solution to Your Customer(s)
- Practice Continuous Improvement
- Provide Professional Growth
- Practice Teamwork
- Provide Accountability
The first three principles will give you a chance to stay in business. The last three are multipliers that will promote bigger and better outcomes. The principles are simple in concept and can be painfully hard to follow in practice. They are impacted by organizational culture, leadership capabilities, understanding of strategy, financial health and many more. No matter what the barriers, choosing not to practice them and make corrections will create an environment that will not go well for the business. On the other hand, practicing them will provide opportunities for success and a much better place to work.
These principles will help anyone at any level of the company determine if we have a chance to succeed or if we are spinning our wheels.
An Example: We Need A Template
I will start off with an example. I was asked or as some would say voluntold to introduce a new tech stack for a project that was in trouble.
- Voluntold - Is the selfless act of volunteering when you have no other choice.
The jest of the problem goes like this. We have a product and it is costly to maintain. We have a product that is hard to install. We have a product with poor quality. We have an organization that in some perverse sort of way seems OK with it. It is not for lack of trying, it just seems that speed of activity is not changing the situation. You may identify with some of this.
So I was asked to make it right. Now this story is much bigger than what I will cover. I just want to use one part of it to illustrate the principles. As with any project, you must have some definition of what you want to build. I am a big agile fan and love self managed teams that get this and move through delivering solutions to their customers. This group was not there. So the conversation goes like this (DL = Development Lead and RL = Requirements Lead)
DL: Where are the requirements?
RL: We have some but they are out of date. They are mostly right.
DL: Great, I have read through some of those and I am not sure I can tell which part is right.
RL: Oh, about 80% is right.
DL: Can we story board out one of the solutions so the team can get started and we can correct the 20% as needed.
RL: We do not have time for that.
DL: So what is the plan?
RL: We will right new requirements.
DL: It seems like that would take more time.
RL: Maybe, but it will be right and we needed a better requirements template and review process.
DL: OK, I have several templates our team has used in the past and I believe story boarding a value delivery for our customers will help determine where to get started.
RL: No, we will build our own template. This is important.
So for the next four weeks, we spent time as an organization creating the requirements template. No requirements, no analysis, no screen mock ups, we just created the template. This little activity pointed out some big red flags and broke several of the six principles.
Define and Own the problem - The governing problem was that we need to deliver a better solution to our customer. The definition of we need accurate requirements was correct but we left off the need to own it together with a line of site to our customers.
Follow to your customer - customers do not use our requirements. They use our solution.We lost site of our customer in this activity. We also lost site of how we must serve our internal customers.
Practice Continuous Improvement - The existing requirements were mostly correct. We failed to ask the question, what is the quickest and best way to close that gap and get moving on delivering better value to our customers.
Provide Professional Growth - Even if the project moved to a new requirements template, the team missed the opportunity to risk growing by story boarding out part of the solution. Staying with what we know can be a blocker for growth.
Practice Teamwork - the development leader and requirements leader where definitely not on the same page and the organization allowed this waste of time and money to go on. The organization even honored it with a line on the project plan with a reviewable amount of hours spent on the task.
Provide Accountability - Given that the process took four weeks needed to be a red flag and that some part of the organization (some leader) should have challenged the time and cost of this activity. It was not, so all left the activity justified and positioned to repeat.
At this point, the response could be to leave and give up. If you choose to stay, you must then face the challenge of how to lead through it. You have your own world of opportunities. Which ones could you get started on today?
At this point, the response could be to leave and give up. If you choose to stay, you must then face the challenge of how to lead through it. You have your own world of opportunities. Which ones could you get started on today?
What Next
I would love to hear some of your stories. Please post them. Also, let me know what makes sense and what areas need help
In the upcoming posts, I will expand on the principles along with some examples of how to move from breaking the principles to living them out.
You mentioned “get people to talk…” A colleague of mine recently said, “Communicate. Do not assume people know what you already know. Put yourself in their place.” I believe that, no matter the development methodology, you simply cannot over-communicate. Communication is one of the keys to all 6 of the principles discussed here.
ReplyDeleteAn example, a few years ago a team I worked with was developing a new application that the implementation teams would be deploying to customers once released. The development team focused on design and delivery of quality code within the allotted timeline. The code is demonstrated throughout the development process through to completion. High-level requirements for deployment to customers were communicated, and, late in the game, the team gets feedback that in some instances the module will be too difficult and overly time consuming to deploy. The data migration process was deemed partially unacceptable. Negotiation followed and then additional work was required. Was it assumed that the development team would just know what the needs were? Could the requirements have been better defined and articulated earlier on? Were the right people contributing to the requirements definition? Did the development team members ask questions and share design options? Should customers have weighed in? Who attended the demos? Lesson learned - more collaborative communication throughout.
Great points. Communication ranges from informal to formal. It sounds like the situation described above lost site of the deployment team as a customer. Iterative development and delivery could have helped with the communication you are talking about.
ReplyDeleteI also agree that over communicating is a better side to error on.
In my view the first step of Defining and Owning the Problem is very important. Typically, "Requirements" tend to have a single perspective tied directly to functionality. It is critical that we understand the customer's way of thinking. Along with that I think it is important to understand what is needed to enable us to provide that functionality. Many a times non-functional requirements come after the functional requirements are defined. These non-functional attributes essentially define the "Quality of Service (QOS)" attributes. If the functionality is delivered without QOS attributes the customer may not be satisfied. This goes back to owning the problem. I think the solution should be an aggregate of inputs from customer and all impacted departments like Sales,Requirements,Dev,QA,IT, and support. This way the solution is more likely to be consensus based, which would further pave the way for natural ownership.
ReplyDeleteKamlesh, I like the thoughts on making sure you look at the problem more completely. I recently heard Jeremy Gutsche (trendhunter.com) state that people place value on the experience and not the features. We have moved from a product view to an experience view.
ReplyDeleteIf I understand what you are saying Kamlesh, the QOS and non functionals play a key role in that experience.
I also agree that having all stakeholders part of the solution is powerful. This requires a strong organization with lots of trust.
If you are in the middle of something like this now, I would love to talk with you in more details about it. Great comments.