Over the course of the last 20 years, I have been both a participant and a leader on multiple programs that started from the ground up. They were called different things at different times, yet they can all be classified as Greenfield programs. For anyone not familiar with the term, Greenfield programs can best be described as initiatives that start from scratch. Literally and figuratively, envision a wide expanse of land on which nothing yet exists but on which something new will be built. For many IT-related programs, the "something new" will comprise new hardware, software, and technology. This is an excellent starting point from which to obtain a mental picture of a Greenfield program.
During the last few years, many people have asked me if Greenfield programs and Agile/Scrum principles can coexist with each other. Unequivocally and undeniably the answer is yes, which normally brings the follow-up: "How, and give me some tips." Below are some of the key strategies that executives, managers, and individual teams can consider following in order to achieve success and avoid colossal failure:
Greenfield contains multiple work streams that range from database architecture to implementation teams. Collective team alignment is critical for the overall program to succeed. Regardless of how many teams encompass the program, collective team alignment can be realized by actively implementing and participating in:
- Overtly simple communication: The most pivotal aspect of Greenfield programs is the way in which the entire chain of command communicates and comprehends the information provided. Companies start down the colossal failure route as soon as different groups decide it's in their best interest to spin the information in different ways. Don't allow your company to fall into this fatal trap. Use the principles of Agile/Scrum in order to provide one program picture.
- Provide the execs with information to determine whether the program is heading in the right direction. If yes, they'll help decide how much funding to provide. Managers and teams could share simple information, such as "Features Completed vs. Features Remaining," to help execs make informed decisions quickly and easily.
- Provide managers and teams with a clear direction based on facts, not opinions. Telling the truth based on these facts will set you free each and every time. Focus on the items that you can control and don't let the other project-related noise affect you or your teams.
- Cross-team coordination: Let's be honest with ourselves here and realize that with multiple teams, some teams will be ahead and others will be behind. As a matter of fact, some teams should always be ahead of others in order to keep things moving in the right direction. Codependent teams should speak face-to-face as often as possible to remove potential impediments. Avoid the "I sent an email" mind-set at all costs!
- Consistent commitment: Greenfield initiatives are exciting. There is a certain amount of buzz that will be created internally as the program starts its lifecycle. Avoid a common pitfall by ensuring that all communication to the outside (sales, marketing, website updates, etc.) is meticulously evaluated and monitored. The excitement can become disjointed if internal and external commitments are not upheld. The best tool for evaluating this progress can be a program feature profile, an excellent tool that can help provide definitive and timely information.
This is the great white elephant for any Greenfield initiative. With "new" everything, the amount of discovery with Greenfield initiatives can be enormous. Initial estimates can and will balloon to astronomical levels.
- Back to the beginning: Use Agile/Scrum principles and make sure that everyone knows what discovery is useful for: continually updating the product backlog. Help teams avoid confusion by keeping the product backlog up to date and prioritized. This practice will help provide everyone with current information in order to make decisions on the programs' continued direction. It will also help your product owner(s) determine what should and should not be included in an upcoming release.
- Avoid the browbeat: Avoid browbeating discovery and/or giving team members an impression that too much discovery is a bad thing. Yes, discovery can and will become frustrating, but use Agile/Scrum in order to continually reevaluate the best information provided at a point in time. Use simple and concise information in order to help decision makers decide where to focus the company's critical resources.
- Get and stay involved: Executives, managers, and employees should understand that discovery will be very high in the beginning stages of the program. This is completely normal and should be anticipated by all vested parties. Again, by keeping your communication overtly simple, everyone should understand how discovery is affecting the entire initiative. Initially, discovery is an excellent means for keeping everyone involved. The real challenge is making sure that everyone remains involved over the course of the entire initiative. Avoid the proverbial "ivory tower" syndrome at all costs, or prepare your group/team/company for an imminent failure.
Are dates the driver?
The short answer is absolutely not. However, this approach should not give the program the impression that dates are not important.
- The funding: Dates have a direct correlation to the allocated financial funding for the program. A key driver is to continually evaluate what business features have been completed and what can be taken to market. Another key aspect to follow is the recognized value associated with the initiative. In simple terms, the value (revenue, customers, market penetration, etc.) attained should be greater than the efforts expended.
- Don't fail at the start: Organizations will set themselves up for failure by expressing the program in terms of dates only. Dates can be effective if they're combined with definitive information associated with how the program is progressing. Avoid the pitfall of thinking that your company will get everything in a Greenfield program by a certain date. Continually use Agile principles in order to monitor and reset deliverables.
- Market/customers: Whatever happens, don't allow your company's management team to make promises to the market and/or your customers for which there is not an extremely high level of confidence! If that's allowed to happen, make sure you prepare yourselves for a demoralizing effect on the teams actually doing the work. Remember that one or two date slippages will give the market an impression that you have an execution and delivery problem.
Provide a playbook
As mentioned previously, Greenfield initiatives will have multiple teams all sprinting toward a common goal. Using the information that Agile/Scrum provides, your company should consider creating one playbook for everyone involved in the effort. The playbook can and should be updated on a scheduled basis. Great pieces of information to provide would include:
- The product: Regardless of what you are building, initial diagrams/visuals will go a long way to making sure that everyone knows what's coming. By updating these in the playbook as necessary, you'll give everyone a constant awareness of where you're heading. A picture, after all, is worth a thousand words.
- The teams: Provide information on what the individual teams will do during the program. Yes, this may seem simple, but it's often overlooked by many organizations. This will help ensure that new and even existing members assigned to the effort have awareness of the collective vision and goal.
- Who's up first: Let us realize that for efforts of this size, all teams can't begin at the exact same time. For example, a database modeling team may need to be ahead of the user interface team and a data requirements team may need to be ahead of a data integration team. Your company can certainly use Agile/Scrum principles in order to create an environment for success. Provide simple visuals that will help everyone understand these basics.
- Print it: Some will balk at this idea, but print your playbook and create a culture where folks carry it around. This goes for the top executives in the company down to the latest hire. When you determine updates are needed, then make sure to take the old information out of circulation. Yes, it is an expense, but it's well worth the effort if managed and implemented correctly.
It's only half baked? Show it anyway!
Let's face it, who wants to show something that isn't perfect? Since the program is working on a sprint-based cadence, make sure that teams show what they've accomplished each and every sprint. Use the following recommendations to ensure success and avoid a program failure:
- Do not accept the statement, "We have nothing new to show" at the end of a sprint cycle. This is a fatal flaw that many Greenfield programs run into at one point or another. Unless you've had a sprint in which absolutely no code has been touched, then something has changed and something new exists.
- Make sure that the demo audience knows that an effective demo can be the actual application or product, a one-slide PowerPoint picture, or even something as simple as someone getting up in front of the room and stating what was done.
- Don't fall into the trap of "It has to be perfect or I'm not showing it." If you've seen this behavior, then your management team has failed the program. Make sure the right mind-set is provided for everyone and continually reinforced.
- A demo should not take hours upon hours to prepare. If it does, then think about another approach to doing the demo. You'll lose your presenter base quickly if they form an impression that hours of prep are required. Again, keep things overtly simple.
General success tips
We've all seen initiatives like these take a nosedive because the basics were forgotten along the way. Below are just a few reminders to help avoid confusion and frustration:
- Infrastructure setup: Talk about this one until you are blue in the face and gain a commitment from everyone. For starters:
- Spend the time and money necessary to create and maintain multiple environments. Programs like these will have environments (development, quality assurance, demo, production, migration/implementation, beta, etc.). If you don't get your environments early, I can promise that your developers and quality-assurance team members won't react favorably to your management team.
- Gain consensus on when and where to deploy your code based on your environments. Nothing will be more confusing for everyone than having multiple code releases going into different environments at the same time.
- Every company is different when on-boarding new team members. I've seen situations where developers and quality-assurance folks join a company and then wait for weeks to get their laptops set. Nothing is more frustrating for new employees who can be productive immediately than to sit on the bench waiting for a configured computer to arrive. Yes, there are many considerations involved in this topic, but make the investment and you'll reap big rewards.
- Staffing (FTE and contractors): Above all, this is where many Greenfield initiatives fail miserably. Resources translate to dollars and dollars translate into budgets. Nothing, and I mean nothing, will cause more angst among the team members than finding themselves constantly moving around to other teams. I've seen this at multiple companies over the years and the end result is always the same: Productivity falls. Just at the point in time when teams establish a good cadence, someone gets pulled off and moved elsewhere. While I understand the need to move skills periodically, I can't fathom why companies continually employ this practice while attempting to remain Agile. Give your program every chance of success and make sure that your resources are dedicated. What's more, don't be afraid to let everyone know what their duration will be. You'll be better off in the long run.