Solar Agile Project Management
Previously we discussed about how you could Enhance Your Productivity with Solar Project Management Software.
Let’s go a little bit deeper and understand, how solar PM software could work more efficiently using agile methodology approach.
- A recent search at Google on Solar Agile Project Management gets 69,70,000 hits.
- Leading magazines like Software Development, PMI, Project Management.com, & IEEE are publishing articles on ‘Renewable Energy Agile Project Management’
- Editors of Newsletters Project Times and Agile Alliance are dedicating a section to Agile processes
Why is there so much interest in this methodology?
Businesses continue to change at a rapid pace. We are in the midst of a chaotic business environment. The organizations rely on software, to be competitive and be successful. Well, it’s good news for technology / software professionals. It is only to be expected that customers want the projects to be delivered as promised, on time and meeting or exceeding the quality expectations.
In order to deliver any project, as well, as a project manager, you need to have a methodology or a process in place. According to Merriam Webster, a methodology is a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures.
I am sure that many of us might have worked on projects, which did not have any defined agile methodology. Without any disciplined methodology, like Code-and-Fix, formal specification may or may not exist. The design, coding & testing are informal. Even though, it does not have any major overhead and requires less up-front planning, it has catastrophe, written all over it. Over time, design deteriorates, which in turn reduces the ability to make changes effective.
This article is about ‘Solar Agile Project Management, which is a set of simple practices, which can easily be understood by development teams and enable them to concentrate on the most important aspect of the solar project, “delivery of the product [Software] to the users”.
Profile of a typical current day project
- Helps the companies to transition from business to e-business
- Uses New Technology
- High Risk
- High Uncertainty
- Must be developed faster, smarter and cheaper
- Volatile Requirements
Many organizations have been employing traditional development methodologies like Waterfall, Capability Maturity Model [CMM] and others.
Waterfall methodology is a top-down methodology that consists of a set of ordered phases, with output from each phase being passed onto the next phase. Due to the nature of the process, it requires that all the requirements are specified up front.
Software Engineering Institute [SEI] worked with the industry and government to develop a software model and software process maturity framework, what is known as CMM. It utilizes a 5-level framework that brings an organization’s software development process from an ad-hoc or immature state to a disciplined and mature development process. CMM’s premise is that the maturity level of an organization provides a way to predict the future performance of an organization. It is based on the experience that organizations do their best when they focus their process-improvement efforts.
These traditional methodologies are good and required for long-term projects. However, often they don’t enable the teams to deliver faster in a typical short-cycle project. Here is a list of a few reasons:
They focus on extensive up-front planning.
Teams must define all details upfront. A small change in requirement may significantly increase the complexity.
One of the most common causes of any runaway projects is poor estimation. In heavy processes, software estimation usually occurs at the wrong time, when the full details are not available at all.
Putting a lot of emphasis on upfront planning is nearly impossible for fast moving targets.
They are predictive.
They try to specify everything in advance in order to gain control. The assumption, based on conventional wisdom is that it will be much more expensive to fix, if the errors in requirement are found near the product release rather than up front. So, the methods try to get all the requirements at the very beginning of the project, before the architecture and coding begin. As the big design is done up front, they tend to be wrong when the actual requirements emerge later on.
They impose a disciplined & repeatable process, to increase predictability. There is an increased focus on process-centric development.
As a project manager in the solar industry, you know about the triple-constraint of Cost, Schedule & Quality. The software development team is faced with a different type of triple constraint also. They are Business Process, Technology & Development Methodology. The team has to definitely grapple with business & technology issues to be successful. On top of that, the team is forced to follow the rigorous procedures of these heavyweight processes, thus adding the third undesirable constraint. As you are aware, only two of the three can be satisfied fully, at best. As a result, it is not uncommon that some teams satisfy the technology and methodology constraints, ignoring the most important business issues. The net result is a failed project, with wasted resources and loss of trust.
I have personally witnessed in a few projects in which the team could not understand the process, but used it to satisfy the management. The process was not properly applied, even though the team spent a considerable amount of time in implementing the process. I would say that a lack of any process would be a better alternative than a poorly understood and implemented process.
General Expectations from Agile methodology in Solar Project
The methodology should be simple. The book, Light Speed Business specifies three things that are essential to succeed in today’s environment. They are Speed, Smart & Simplicity. They form a spiral. When all the three are present, it is a virtuous spiral and keeps going up. Even if one is missing, it turns into a vicious spiral and falls down. The chosen methodology must be simple enough to enable the smart people to concentrate on business and technology and deliver products at a high speed. “A methodology should be as simple as possible to get the job done. If you make the requirements a burden rather than a help, then people will resist following them”. – Dr. Lewis says in his book, “Project Planning, Scheduling & Control”.
The agile methodology must make it easy for the team to deliver results at frequent intervals to the customers.
MIT Sloan Research has the following four practices of successful projects.
- An early release of the evolving product design to customers.
- Daily incorporation of new software code and rapid feedback on design changes.
- A team with broad-based experience of shipping multiple projects.
Major investments in the design of the product architecture.
The methodology must provide support to the team to learn easily and adapt.
A Baseline magazine article “When Bad Things Happen to Good Projects” says that different skills and practices are required to solve different projects and problems. It postulates a continuum of threats, from variation to chaos. It quotes a Sloan Management Review, “Managing Project Uncertainty,” which states that more solar projects face multiple kinds of uncertainty, like Variation, Foreseen uncertainty, unforeseen uncertainty & Chaos. Chaotic solar projects are those that may invalidate goals, over and over with no clear structure or endpoint. The authors suggest rapid learning and adapting as the primary requirement for success.
The methodology must be flexible.
The best practices of the earlier decades must give way to next and newest practices for these high-risk projects. Many e-business projects are similar to research and development projects. The one important difference is that these projects do not enjoy the same time cushion of the R&D; projects. The methodology must provide more flexibility for the team. It must allow the team to adaptively operate in a complex environment.
Do we have any such methodologies?
There are several popular lightweight methodologies that are used around the world. They are:
- Extreme Programming
- Feature Driven Development
- Lean Development
- Adaptive Software Development
- Crystal Methodology
They have converged under the banner “Agile Methodologies”. These have helped companies worldwide to deliver results in complex solar project areas. The gurus of these methodologies met and produced a “Manifesto for Agile Software Development”. It reads as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a project plan.
That is, while there is value in the items on the right, we value the items on the left more. Detailed description of the different methodologies is beyond the scope of this article. Let us go over the general characteristics of an Agile Methodology.
Agile projects place heavy emphasis on the early and continuous delivery of valuable software. Agile believes in delivering working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Agile projects are iterative & incremental. The most important thing is to deliver the working software in the hands of the users. The product is incrementally developed and improved. Massive up-front planning is not done. The team gives continuous attention to technical details.
Responsive to change
Change is part of any project. Change must always be considered as an advantage. Agile team welcomes changing requirements, even late in development. It harnesses change for the customer’s competitive advantage. It does not attempt to control changes. The team decides whether to incorporate the changes in the software, when and how.
Agile places a lot of emphasis on teamwork. Customers & developers are on the same team. So, customers are always available to the developers for feature prioritization or product feedback. Developers collaborate with each other. Due to the team structure & environment, the problems are resolved faster. TEAM stands for Together Everyone Achieves More, right?
Communication is very vital for the success of any venture. Communication enables knowledge transfer as well. People are usually more effective in informal methods. A person can understand more by talking to another on the white board than by reading several pages of a manual.
Good Team Environment
The environment also determines the success of an agile project. The Agile Project manager must have good recruitment strategies. An environment of trust is made available. People are empowered. So, they assume responsibility for making decisions for collective benefits. The team is allowed to take risks.
Simplicity is another essential component of Agile projects. Simplicity provides a real value in high change situations. The team employs simple approaches in design and coding. Agile project provides a simple set of rules and it is easy for the team to follow.
The team uses intermediary artifacts, like models, only when absolutely required. In any project, users define requirements. Rather than writing very detailed functional requirements and specifications, Agile developers ask the users, what they want and implement. The team uses high level specifications to guide the solution. Agile process does not see any value from a lot of low level detailed specifications. The project processes and procedures are also kept very simple.
Agile process provides you a flexible methodology. It is very much people-oriented and empowers the developers. As a project manager of a high-energy, agile team, you will
- Act as a coach
- Hire the right people
- Recognize the team effort
- Provide a good environment
- Devise meaningful metrics
- Keep on delivering quality software to customers.