Software project management: Why the changes & challenges are bigger than you think

The original article was published in LinkedIn (https://goo.gl/dmiatb)

.

If Agile software development questioned the existence of project managers, technology advancements are fast digging the grave.

The landscape of software project management* has changed rapidly over the last few years. This is mainly due to many organizations adapting Agile software development frameworks and technology is advancing at an exponential pace.

These factors demand that software project managers change the way they have been thought & practiced for many decades.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change — Charles Darwin**

 

 

Agile teams do not require a project manager, theoretically!

Why?

1. An Agile team is cross functional and self-organizing. It has the required skills to develop the product and also members get organized around the tasks. Thus it does not require a person to “manage” or to dictate what to do each day.
2. There is no big upfront planning in an Agile project. That is because Agile teams value “responding to change over following a plan”. Further there is no need to painstakingly monitor how much % is completed each day. And it is not possible to compute scheduled or budget variances.

The basic project management activities such as planning, executing, monitoring & controlling are not required for an Agile team in its traditional form.

So what does an Agile team require?

An Agile team needs a problem solver, a leader but not a manager. Agile teams are good at solving technical problems. But they need someone to lead/guide them, when they face complex non-technical problems.

For example, they need “a person” to work with the Product Owner (PO) when the requirements are not clear. In most cases, the PO is busy and “that person” needs to find a solution which works both for the PO and the team.

In another example, a team faces frequent production bugs & user complaints. The team needs a person to help mitigate the situation and solve the problem.

The closest person to fulfill these demands is a project manager who is skillful in solving complex problems.

The must have skills for “today’s project managers” are “Understanding, & Solving complex problems”

The exponential advancements of technology

Technology today is advancing rapidly but software related technologies are advancing at an exponential pace.

It is said that if the average car had advanced as quickly as the computer over the last 35 years, cars would get 3,666,652 miles per gallon and cost less than $5,000 in 2017! 

These advancements are changing how a project manager works. A software project manager must face two types of advancing technologies. One is software development technologies & second is general technology advancements such as AI, BOTs, IoT, etc.

1. Impact from software development technologies

It’s difficult for project managers to keep up with advancing software development technologies when software engineers themselves struggle to cope with it.

Many advanced tools enter the market daily  creating a complex web of tools. For example you can use NuGet to share code, Docker to automate the delivery. In fact a tool can be found for every sphere  of software development.

Gone are the days where the source code is compiled & manually zipped to a CD for transport. Now it is an era of continuous deployment where production warm ups happen in the production staging slot.

Not only tools, many software development concepts itself are hard to understand. Object Orientation was difficult enough but now things are extremely complex. I took this example from “WebAssembly”

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications

https://webassembly.org/

Although written in English, the description is incomprehensible. 

Complex technologies, tools & concepts create complications for software teams. A “Project manager” should have an in-depth knowledge to comprehend technical concepts to lead & guide the team to resolve  these problems.

A few examples:

1. The build breaks and the team says that it is due to a missing NPM package. If you’re a non-technical project manager, you have no clue about what a  NPM package is or why it is needed in the first place.
2. In a bug triage, the team says the bug is caused by a wrong “dependency injection” — A non-technical project manager may wonder about the injection they are referring to.

A project manager should be knowledgeable in these technologies unlike  in the past, where it was only required to monitor the project plan once it is created.

2. Impact from general technologies

General technologies refer to technologies & products available for general use such as IoT, GPS, AI, BOT, AR, VR, Nano technology, etc.

In the past, new technology was easily understood and converted to a business product. Today, business people struggle to understand these technological advancements to make products out of them.

For example, when the World Wide Web launched, it did not require much brain power to understand the potential business uses of the Web. It was the same when James Watt invented the steam engine and Johannes Gutenberg invented the printing press & somebody invented the wheel.

But today’s technological advancements are so complex that it is virtually impossible for a non Ph.D. holder to understand the business use of it.

For example, AI is now readily available. We hear amazing stories on how AI is used to enhance products, lives, etc.

If you are the PO of a system to track train schedules against the actual arrival times; how do you make use of AI to create a better product? Although it looks simple, it’s not easy unless you have a good understanding of AI concepts & technology. Same goes for “Digital Twins”, BOT, AR, VR, and the list goes on & on. 

The responsibility of mapping technology to possible product/business cases has been delegated to  project managers. This requires him/her to have a good understanding of general technologies.

Futher, Technologies today are creating new economies  for them. For example, the concept of API economy is created based on the technical concept of Application Programming Interface.

The message is simple, if you are a software project manager today, you need to stay on top of the technology game.

Summary

Agile & technological advancements have turned the software project management profession upside down.

• Technological advancements have converted problems from business problems to technical problems (making it difficult for a non-technical project manager to solve).
• The adaptation of Agile software development methodologies has  transformed project managers from managing tasks to become problem solvers.

If you are project manager, embrace the change now! Sharpen your problem solving skills & master the technology.

How the future would look like

It’s difficult to predict the outlook for  project management. Project managers may have to manage well knowledgeable teams spread across the globe.

• Automation will increase and some teams may code for BOTs  The software products will be much more complex than ever
• The project manager role will diminish giving rise to role of the project leader
• Project managers could be  replaced by a “project management bot”

Foot notes

* Mainly these challenges are for  project managers in the IT sector. Project managers from other sectors is less pressured by these factors.

** There are debates about whether this quote was actually made by Charles Darwin.

Refer the following link for  a good discussion regarding why Agile project management exists even though there are no project managers in Agile teams.

https://www.linkedin.com/pulse/myth-agile-project-manager-anthony-mersino/

Agile

Ken Schwaber's Blog: Telling It Like It Is

I am returning from the Agile Alliance conference. I thought I would share the answer to several questions that I was asked in my session:

1. What is “Agile”
Any software activity that conforms or attempts to conform to the values and principles of the Agile Manifesto for Software Development.

2. If you could add another value to the Agile Manifesto, could you state it?

We value practices, tools, consulting, coaching, and software organizational work that continuously improve their adherence to the Agile Manifesto
OVER
Tools, products, methodologies, processes, practices that only use the word Agile to market themselves to make money and whose correlation to the Agile Manifesto is coincidental.

View original post

Velocity vs Agility

I just wanted to compile few interesting posts which is going around last couple of years in the Agile Circle. It is about using velocity as a productivity measure. Here are the few references

• Joshua Kerievsky – Stop using story points: http://www.industriallogic.com/blog/stop-using-story-points/ 
• Jim Highsmith: Velocity kills the agility: http://jimhighsmith.com/velocity-is-killing-agility/ 
• Matt Block: Is working software enough: http://www.developmentblock.com/2011/08/25/is-working-software-enough/

In summary what all of them mention is that it is wrong to use the velocity as a productivity measure to reward or punish the development teams. If the organizations use “Velocity” this way, the problems would be

1. Lose focus on customer value and creativity
2. High focus on estimates which may be a waste
3. Teams would inflate the story point estimates
4. Etc.

Rather velocity should be used as a measure for capacity planning. For example size of the backlog divided by current or average velocity, can provide a fair idea of how many sprints it would take to deliver the product backlog.

The Bad Side of Prototyping

You may have heard many good things about prototyping. How much money it has saved, how much time it saved, how much effort it saved, etc. Those are absolutely true,  nothing wrong with them.

But think a second, is everything is good about prototyping? Do we have any downside of it? Well may be. Lets look at that further and focus only on the throwaway prototypes here.

It Kills Thinking

What? Should the prototypes suppose to generate ideas? Yes it is true but;

Imagine that you have a busy customer. You discuss the requirements with him (may be in high-level) and step by step, you come up with the prototype. You will get the feedback on the Prototype. But when time passes (and  if the customer gets busy) he tend to agree with what you come up without much thought from his end. The main reason for that is customer knows that you have got hold of the requirements and therefore he takes easy and pass the responsibility of requirements to you. Good to be a customer. 🙂

Secondly what about the development team? Isn’t it common that when you have a prototype, they tend to follow  exactly as in the prototype rather than thinking what is correct? Need not to mention that Prototype can be wrong. One common excuse on this lack of thinking is that the prototype has being discussed many times and agree with the customer so that is the ultimate truth and why change it. This happens specially if the person who did the prototype is not a permanent member of the team.

Effort of Maintenance and Level of Confusion

Once you build the Prototype, you need to maintain it. If not, it can lead to many confusions.  There are two situations where a half baked prototype can lead to confusions.

• In the Middle of Requirement Elaboration – In this case, you start building the prototype to keep the requirement elaboration flowing. Then after each round of discussion, you keep on updating the prototype based on the feedback. After sometime, you get tired of updating and most importantly now you are familiar with the  logic of the system. These two factors lead not to update the Prototype. Sometimes you tend to refer to the meeting notes. The consequence of this is that you are nowhere with the requirement documentation. The Prototype is not complete as well as there is no proper requirement document.
• During Development – Secondly even if you lucky to sign off a complete prototype at the end of the requirement elaboration, but there will be many further discussions during the product development. These updates to the requirements get rarely reflect in the Prototype. This can lead to problems when the acceptance testing is done.  When the Prototype is used as a requirement document, then you will find it not updated and confusion happens on what is the correct requirement.

Therefore it will become mandatory to maintain the Prototype if you start building it and to maintain a Prototype throughout the Project Life Cycle itself is a project of its own.

No Documentation

Isn’t it good? May be in certain times, but not always.

The reliance of Prototype will eliminate or reduce the requirement documentation. This can lead to many different kind of issues. To list a few

• Difficulty in freezing the scope –  Many customers would require a requirement sign-off. This is difficult when you have a Prototype.
• Inconclusive Requirements – Certain requirements may not be conclusive. For example, it is difficult to describe the different kind of data which will be listed in a grid, through a Prototype. Therefore the developer will not have an understand what sort of data and what characteristics of them to be expected (Domain of the data). To explain further, lets say you have a Grid and you are worried about the alinement, width of the column, etc. A comprehensive document can give inside into those unlike a Prototype.
• Typical Issues of Lack of Requirements Documents – For example, product not confirming to what customer wants, bugs, etc. etc.

What to do with Business Logic

It is true that a Picture is worth of  1000 words but there are things which Picture can not describe. For example, it is very difficult to describe a workflow using a Prototype. In general terms, the Prototype is a very good tool to explain the User Interface but it cannot describe the Business Rules of a system in the same effectiveness.

 

Loss of Focus

On a blog post in a different line of topic in Prototype, David Bernstein describes that users focus on what is missing rather than what is there in a prototype.

Conclusion

I am a strong advocate of prototype and in which I have seen many benefits (not to mentioned that sales team uses Prototypes win projects as well). I just wanted to list down few points where the Prototyper should be careful so that he can avoid those negatives and come up with great results.