#Three Deadly Sins of Software Development #agile #hubris

In my experience, I have encountered three deadly sins in Software Development. Project teams can overcome almost any problems if they don’t fall victim to these three deadly sins. Unfortunately we seem to have progressed through these deadly sins throughout the years as we get more and more experienced in Software Development.

Technology-Centric

Our first deadly sin was the sin of being technology-centric. The first aspect of this was the behaviour in the 1970’s where Information Technology professionals had a belief that they knew what was best for clients and would essentially decide for the clients as to the specific type of functionality delivered. I can remember early on when we still gathered requirements from the users, but we sought no validation on the design or interface. We as professionals know best in regards to how those components should be designed. Even our terminology set the stage for the principle that the business was not informed enough to make decisions on their own. They were only ‘users’ after all. Information Technology professionals would create the system and the business could simply ‘use’ the system we created. Nothing more.

The second aspect of being technology-centric came after we begrudgingly accepted that the business were more than just users and should validate the system design and interfaces. OK, we will let you control that aspect, but Information Technology Professionals will control the selection of all the technology and patterns that lie beneath the interfaces. All of those technology choices must remain with the Information Technology professionals and it would be beyond business users to provide input on technology and patterns selected. Information Technology Professionals will decide on all architecture without collaboration.

Thankfully we now understand that if a technology or architecture is truly better, that should result in more value for the client early and often.

Methodology-Centric

Shortly after being technology-centric, we flowed right into the methodology-centric phase. Alright Mr Client, you define the requirements and value that the project will deliver, but we will define exactly how we will deliver the project. This started out by defining a very specific process for the Waterfall Software Development Methodology, but has evolved throughout the years to be equally specific and constraining processes for hybrid and Agile Methodologies.

In short, any methodology that a project follows without customization for a client, project team, or project is flawed. I’ve always thought how curious it was that Agile proponents once freed of the shackles of Waterfall were so eager to put Agile shackles on every project they saw.

Topology-Centric

And the final deadly sin is one that is a bit recent to the dance, topology-centric. I use topology-centric to refer to the desire by Information Technology project teams to be embedded at a very senior, strategic level for the project. Many times the Information Technology solution can be made better if Information Technology Professionals can work together on the business problem and not just the solution. It is ironic that early on Informational Technology was trying to limit the access the business had to Information Technology components of the project and now the business is in charge to limiting the access Information technology has to the business components of the project.

The more things change, the more they stay the same.

To be clear, the deadly sin is not to that Information Technology is denied access, but rather that Information Technology demands that they should be granted access by default.

Summary

Information Technology Professionals have to remind ourselves we are a service and need to embrace the servant leadership in all aspects of project delivery.  We as Technology Professionals only encounter these deadly sins when we think we know better than the clients. If we avoid these types of Information Technology Hubris, our projects have a much better chance of success.

Advertisement

#Agile #Sketch – A process for #Agile solutioning

I was discussing how I wanted to approach an Agile project with my team the other day and came across a pattern that I typically find comfort and clarity in. I like to Sketch. Not the drawing type of sketching – but the project type of sketching.

I like to draw and sketch everything at a high level and then fill in the sketch as I go along on a project. I find these sketches extremely valuable. I also use various types of sketches:

• Schedule – high level project plans
• Architecture – high level design
• Strategy – high level objectives and scope
• Estimate – high level effort plans

I’m sure there are others.

The concept is two-fold.

1) Create a sketch so that it provides internal and external clarity in regards to what the team is doing and creates a shared vision.

2) Allows the team to think through the sketch. Sometimes oversights, inconsistencies, and errors are only found when you dive down into the details.

The situation

In this situation on the project, I was proposing we create a sketch of the test solution we were going to create. I felt this would be valuable as a method to confirm all the business scenarios that we felt this project needed to address. We would not define all the individual details about the business scenarios, but confirm at a high level, the X business scenarios we would have to ensure we do address and define in more detail in the future.

A colleague of mine asked whether this was a waterfall process.

It caused me to pause and think. Was this a remnant of waterfall processes I had used in the past?

In retrospective, my preference for these sketches seems to be to be very Agile. I am doing what I feel to be the minimum amount of work required. Although these sketches do imply some serialization, I don’t think serialization automatically implies waterfall. I believe excessive and extremely detailed serialization implies waterfall. Some limited serialization to create shared vision and mitigate risk is very Agile.

I viewed what I was proposing to be very similar to a User Story Map. A small amount of time to confirm vision and gain agreement with the team and clients on what the requirements are.

I also saw an analogy back to my video game days where you struggled to get to the next checkpoint. Once you got there you wouldn’t lose the progress you had made. I felt these sketch checkpoints were extremely valuable to spend a small amount of time to confirm the vision and think through the solution. If we had a disagreement we could reflect back to the sketch as we confirmed we had agreement at that point in time. In this way it very much is a risk mitigation strategy.

Flow

I think my comfort with the process of Sketching can be related to my concern on whether a project can be done fully in Flow without some up front planning. I believe that Flow can and should be used 100% on repeatable and stable processes, but as we know that sometimes projects can be called neither stable or repeatable.

Rather than having scope, design, or architecture organically grown from a collection of User Stories, I do think that some planning should be done to confirm visions and think the solution through. Whether you call these constructs sketches, User Story Maps, Plans or widgets is  not important.

There are two critical aspects

1) Do some level of upfront planning/sketching/mapping

2) Do as little planning/sketching/mapping  as possible

Summary

We need to be very careful in the Agile community that we find the appropriate solutions that mix Agile with Traditional approaches.

When #agile isn’t the best thing for the client

I am presenting with two other friends on Agile in a non-Agile environment. Some of our first discussions on the matter was commenting on how the topic itself was confrontational and somewhat elitist. Almost putting people would could do more pure Agile above those that had to compromise on how they implemented Agile. In many situations, I had seen the discussion of these projects being referred to ‘bastardizations’ of Agile. How dare we do less than what was written in the books? How dare we do less than what was proposed by the experts?

Our first thought was to again reinforce that Agile is about finding better ways, no matter where you are on the Agile/Waterfall continuum. Our second that was to reinforce that using Agile in a non-Agile environment should not be viewed as a lesser implementation of Agile. As long as the client is getting the most value from the application of Agile, it should be viewed as successful as a more pure Agile project.

What is Agile at its heart?

When we discussed what Agile is at its heart, we came up with two things:

1. Reducing Inventory (Whether they be documents, features, or wasted processes)
2. Shorten Feedback Loops (On deliverables and on the use of features in Production)

Who decides Value?

Often times I believe we as Agile professionals get caught up in determining what is valuable for our clients. This was a major fault with the Waterfall processes, and I fear Agile in falling into the same trap. In the past, Waterfall projects had less frequent interactions with clients and the projects and professionals were expected to make decisions for the business. One of the first benefits of Agile that I saw was placing the full determination of priority and value clearly back into the hands of the client. For too long, projects had wrestled the full determination or priority and value away from the clients and the processes Software Development projects used were considered mandatory and not open for debate.

But now I fear that we are slipping back into that black and white Worldview. But instead of the Software Development professionals informing the client that we know what is best for them, Agile Software Development professionals are informing other Software Development professionals that we know what is best for them. And if some projects and professionals are not as Agile, they clearly have bastardized Agile.

Three statements I heard in the last week were:

• Business Analysts have no value
• Estimates have no value
• Documentation has no value

From whose perspective? I would be hard pressed to find any client I have worked with in the past twenty years that would agree with these statements. I agree that doing documentation and estimates excessively can provide limited value, but in the end the person that determines that value is the client.

The statement that we came up with for the presentation speaks for itself:
“More Agile processes can deliver less value for some clients.”

 We present at the Agile Winnipeg Users Group on May 10th. Hope to see you there and hear your questions and thoughts.

Dear #Scrum Letter

Dear Scrum, I am sorry I have to write this in a letter, but I just found you to be distant and inflexible lately. I must admit when I first met you I was charmed by your processes and procedures. The form was liberating, I never felt so alive and everything seemed so clear and concise. But slowly I must admit the rigidity of the process has not allowed for the freedom that I and my projects need.  I really did need a process where I could add requirements during a sprint when it made sense. I didn’t want to be limited in the duration of retrospectives if I thought there was more to discuss.

I guess I just need space.

And to be brutally honest, I was feeling really bad about referring to my team and clients as chickens and pigs. Although the metaphor was cute, it ended up being more divisive than anything. And I hated being referred to as a Scrum Master. The actual role seemed to diminish my value as a Project Manager and made me just a coach of the process instead of a valued team member. I felt that I wasn’t actually part of the team anymore.

I guess I have changed. It is not you, it is me.

More and more we just talked about Scrum and how we had to follow the process very diligently. Our discussions were only focused on Scrum topics. “What makes a good Product Owner?” and “How to be a better Scrum Master” were the main topics. It seemed all we ever did was talk about you. We never talked about my feelings on User Story Mapping, Paper Prototyping, or other new methods that made me feel alive. In short, we were in a rut and not exploring anymore. We were just using a process for the sake of process and it felt like, well, waterfall.

I know those words hurt and I know the process is better than waterfall, but I felt we weren’t growing.

No, I haven’t met anyone new. But there is a whole world out there and maybe I need to date for a while until I discover someone I can truly be happy with. I just know I need someone who wants to change and adapt as much as I do. We will always have those items I learned from you and I will always have the Daily Stand ups, Retrospectives, and Technical Spikes. There is so much you taught me and you will always have a special place in my methodology heart.

I hope we can remain friends a maybe catch a movie someday. Maybe the Hobbit when it is released in 2012. Stay in touch.

Yours Truly.

Terry