Agile approaches and the risk Trade-off

Blog post
added by
Wiki Admin

We were discussing Good, Bad, and Ugly on Agile. As we were, we were able to appreciate many points on Why Agile? article on wunderkrautNot setting too narrow a goal on techwell.com as well as a slightly aligned and counter article on Fixed Price Contracts for Agile Teams

Here were some of our takeaways.

The Good – Agile helps reduce risk of not meeting project goals.

If the project goals are to stand up a new service, application, use case, workflow, visualization, data feed, or other very specific components, Agile will help you launch those speicifc components solving specific user stories within epic problems rapidly. You can also blend Agile development with lean to make sure you launch beta, soft, or early versions to a closed set of known users or under a brand to show to anyone. This can avoid embarassing deployments and also expose aspects missed – negative testing (think 5year old pounding on keyboard or tablet), security testing, load testing, or experience modeling. You have a better chance of this “Agile lean” blend to finding out early on the adoption and rollout issues. The Agile Lean approach allows you to move final decisions on features and form to when you have due diligence of mockups, prototypes, or initial deployments at smaller scales, which allows you learn are you go, and decide when you know, at least investment cost.

This AgileLean approach works for component or service architectures. Keep in mind, it does NOT work for legacy architectures where the architectures themselves are not flexible enough for agile development, refactoring, architecture, or deployment. Using Agile in these cases are actually HIGHER RISK as the learning curve discovers problems very late in the phase, and thus causes more problems, higher cost. So if you are doing system integration with new and legacy, balance where you can and cannot use AgileLean.

Given the focus is on the project goals, dont set the goal too narrow, and be prepared for your requirements to change, flux, and adjust as you learn and focus on achieving that goal.

The Bad – You will likely not hit the your defined project scope.

Some ask, is this bad? Was the initial project scope right anyhow? Were there too many features, functions that were on the nice-to-have list that snuck into the required for business? Sometimes Agile will help trim the fat and focus to make sure we do not shop hungry.

Then again, where it is bad, some of the initial scope desired was key, but turns out the architecture chosen and discovered through the learning curve led you down a wrong path, and there is a few re-starts that need to re-occure to introduce new patterns, components, operating concepts, etc. This could happen multiple times if the architecture reset is done with only the development and management project team. A way to avoid this is any re-architecture needs to involve the proper stake and stockholders governing and investing in the program. Whereas Agile tends to be responding to the functional manager, if the design, flow, and strategy needs to be re-set, then those questions need to go beyond the functional manager, and back to the right stakeholders.

The Ugly – Government Contracting is not ready for Agile… today

Consider if you do firm fixed price contracts, how you define deliverables up front. Articles like Fixed Price Contracts for Agile Teams give you ways to play the cards you are dealt and work within the Firm Fixed Price framework, but there is a reality. If the epics are in development, user stories unknown, specific components unknown, make sure the contracts are setup to define deliverables that show developing and deploying x # of 2 week sprints in desired environments with desired scope from clients that assumes these type of skills. Even that level of description may be complicated to reply to. How much level of effort per sprint? Are the technologies hardened or could new ones come about (Answer is the latter)? Are the sprints to productions, staging, or soft-launch? Agile development or Agile Design is VERY hard to do in fixed contracts. Legalities do tend to cause some hiccups.

Then again, the other options of T&M have their own problems of accountability, but that is a more mom and apple pie argument.

We are still seeing RFP and RFIs go out asking for the enchilada and waterfall. Its what the Contracting Officer space knows. “Systems” are being asked as the common jargon, but the layers of “services”, “components” are clearly being demarcated to help with agile bidding. This typically that does not bode well for Agile UNLESS if it prescribes system, it also “services” and “components” solution architecture principles that forces the responders to respond with an architecture that itself allows for Agile. You cannot do agile on traditional tightly coupled architectures. You end up just doing iterative instead at best which does have its differences

And somewhere in between, bidding as lowest price, technically acceptable is the WORST agile solution, as the only capability of doing that is responding to the technical specs, and not what is really needed – Agile-skilled, impassioned “Ninja” developers who can adapt to changing technologies. LPTA would bring in the Junior developer, and since a Senior developer has much increased output for Agile Development that goes live, and reduces the cost of the acceptance period as they understand how to design code for integration, negative, security, and load testing, and for the O&M teams to manage, deploy, and support.

So if you are pitching Agile, beware if the customer is saying great, now respond to that FFP or competing it LPTA.

Medieval Project Management is actually a real thing to learn about

Blog post
added by
Wiki Admin

Staffing solutions is a major part of project management. Internal staff, low-cost staff augmentation, consulting project teams, embedded consultants, employees other duties as assigned, employee working groups, employee standing teams, consulting advisors. All these solutions help address gaps in individual skillsets by bringing others strengths.

The reactions and solutions in “Handling delays on Internal Projects due to skill gaps” help address bringing in consultants and focus on the timing being right-sized and with very clear defined lines. This actually goes back a long ways, to the initial western world village-sized projects. Now urban center feats are well-documented large enterprise projects efforts and were done typically with a fair-amount of dictatorship. But agrarian or travel towns did not have such authority, resources. Smaller kingdoms completely relied on advancing barracks, granaries, resource production, city walls, and maintaining people in the kingdom to advance –both for the security of the city, but being honest, the advancement of the monarchy.

There are actually several books on “Medieval Project Management” (i.e. here) that goes into how kingdom projects were managed – both fair and beloved kingdoms and ruthless or poor kingdoms.

Here is an example, which illustrates one thing – not much has changed in the staff management aspects:

A well-liked king has a goal to build a moat and bigger drawbridge to allow both larger carts to come in and out of the town, while allowing for protection against marauders. The townspeople have never built this before and certainly not to this complexity. The king knows of another town where it has been done before and suggests to bring in this help.

The townspeople say “we can do it”. The king knows loyalty is a prime asset, and completing a project, with townspeople at work creates just that. The townspeople, unfortunately, struggle with designing to the new scale and has spent more than anticipated, and nothing is yet built nor designed to work.

The king, recalling loyalty is key, doubles-down, but attempts to buy back risk by saying he will bring an advisor in.  The townspeople once again say “we can do it ourselves”. The king takes this risk and approves the project without delay. Delays continue, and once again time and money from the coffers pass.

The king noting they are very far behind, and other towns now have competing sized bridges and moats, now says lets bring in an advisor and a designer who recently finished these projects, but you can still be proud by building the bridge. The townspeople say “we can do it, we just need more time, we almost have it figured out, we need more townspeople”. The king now irritated, knowing loyalty is a major asset, once again reluctantly delays, as now half the town is involved in the project.

Unfortunately, a year has gone by without a new bridge. The marketplace is stagnant, other towns are growing, jobs in the town are now stagnant, and the king knows he can wait no longer. Now, the townspeople are angry they are overworked as they have to work more to make enough.

The king final says, I have now paid the others to take over the project, we cannot wait any longer. The king could resort to heavy penalties, but with half the town, and buried deep, any swift hard actions could result in revolt. Instead, he issues a stern decree, citing their failure, and he has now turned the project over, and the costs are now quadrupled (original costs doubled by failure, plus a double-cost rush order from outsiders and the king must now provide extra protection and oversight for the outsiders to just get started)

The townspeople did not say “well, he gave us a chance” and we were gainfully employed. The townspeople were not thankful for the work on an incomplete job. Instead, the idea of a new marketplace is at an all-time low (though all other towns are flourishing with the new marketplace). The townspeople spread rumors of any sign of delays, weakness, or possible conspiracy or even sabotage. The king must spend time mending the townspeople’s now unruly position.

The project is finished, quadruple costs, double the time, and unfortunately, economically, the shift has occurred. The townspeople decide to uproot and go to the next town anyhow as they heard about how their marketplace is bustling with new jobs and goods as they were able to complete the new wider drawbridge that this king couldn’t and the kingdom goes into dark times trying to recover.

Not much has changed from medieval times in corporate cultures. Balancing the culture health of the company is a big deal. The perception that happy employees produce 1.5-5x as much as unhappy employs is slightly true. But it is not about happiness. Note the story talks about the townspeople wanting to accomplish a big project and would be proud, and the kingdom would expand, and townspeople would be loyal and thankful. Happiness was not in there.

But, the townspeople also had a lack of vision. The king gave a major contract to an untrained, demanding union with a sales pitch of the low price of loyalty, and technically we have done it before. Without a measuring device to objectively allow pulling the contract back, the contract modifications continued, and the king was now all-in.

The king can take the risk on such a contract award – The king did not ask for an initial task to prove their merit. The king did not treat the award of the project to his own people like the award of a performance-based contract to outsiders.

Conclusion: Any project you budget for, award it and set the measures for success whether it is done by your staff or outsider consulting team contract.

All projects require milestones (another medieval term continued from Roman times), clear objectives to guide quality levels and deliverables for scope and some semblance of budget and resource management (whether it is time and materials with a not to exceed, or fixed-time, fixed-price phases).

The similarities are the same – the project failure was not the townspeople. Just like the project success is on the king, or the executive, the decisions on project staffing are on the executive. Take that measured initial risk, but if metrics are showing clear, you need to adjust, using the agreed measure failure as the guidance to approve the switch.

Go Code Colorado Open Data Effort is going into its final weeks

Blog post
edited by
Wiki Admin

States all-around have gotten into Open Data movements. Colorado has as well, and their recent Go Code Colorado effort is a very unique entry into this foray ( http://gocode.colorado.gov/)

Go Code Colorado was created to help Colorado companies grow, by giving them better and more usable access to public data. Teams will compete to build business apps, creating tools that Colorado businesses actually need, making our economy stronger.

 

The following is a great video that summarizes the event as produced by the State and one of Xentity’s colleagues, Engine7 Media.



Get Adobe Flash player

Xentity is very proud to be supporting this innovative Government Solution

Xentity was awarded IT consulting support for the the Business Intelligence Center platform and data catalog which supports the now branded Go Code Colorado initiative. Xentity’s consultants have provided the data and technology resources to manage and advise the publication of public sector data to the Colorado Information Marketplace and to provide technical support developers who participate in the Challenge. 

Xentity primarily has provided data platform support. We have provided data readiness analysis, data architecture guidance, project management, and the data analysts to “wrangle” the data (aka ETL) to get the datasets onto the platform. We also have provided the IT and data support on-site at the multiple locations and events to assure the challenge participants and finalists are getting the support they need to be successful in accessing and using the data and services. Finally, we are supporting the technical review of applications to assure these applications can have a life beyond the “hackathon” stage.

The final stages are coming the first 10 days of May. The 10 finalists have proven to demonstrate very viable solutions to achieve the goal of helping make our economy stronger. 

Some more background and detail on how we got here

(The following is from the State as guidance to this effort)

 

Colorado government agencies possess large volumes of public business and economic data. This data can help businesses with strategic planning, but it exists in so many different places and formats making it difficult for that most businesses to use it. The Secretary of State’s office will address this problem through the creation of the Business Intelligence Center (BIC). BIC seeks to aggregate and analyze data available to the business community.

This effort is led by the Colorado Secretary of State. The Secretary of State’s office interacts with hundreds of thousands of business entities, charities, and nonprofits in the state. The Secretary of State’s office collects, manages, and disseminates large amounts of basic data about those organizations and wanted to make the data useful to Colorado businesses. 

The Department sought to make this data more useful and collaborated with the Leeds School of Business at the University of Colorado to publish the Quarterly Business and Economic Indicator Report. This report combines Department data with other economic data collected by he Leeds School to provide meaningful economic information to the business community. For instance, new business filings are a leading indicator of job creation. With this and other information provided in the report, the business community can make smarter decisions that will grow the Colorado economy.

Since first publishing the report in 2012, the Secretary of State received comments from many members of the business community asking to see more detailed data regarding economic trends 
in order to better understand the distribution of commerce in Colorado. This includes access to the location, size, vibrancy, and concentration of key business nodes. While this level of detail would be tremendously helpful, the Department cannot provide the information because multiple state agencies collect the desired data and it is not readily available in a common place  or even a common format.

A central data collection point is needed. During meetings with other government agencies, Department staff concluded that these data requests could be met by aggregating all the information spread throughout various agencies and databases into a single tool by breaking down agency silos and better cataloging existing resources. Department staff also concluded that access and availability to the data is not enough. In order to make the raw data useful to the vast majority of business owners, data analysis and visualization tools are needed. These conclusions led to the Business Intelligence Center project.

The Business Intelligence Center consists of a centralized data catalog that combines public data into a meaningful tool for businesses. 

The vision for this project is two-fold. First, it consolidates public data relevant to businesses on a single platform. Second, it gives business the tools to make the data useful. The second goal is 
achieved through a civic apps challenge—the Colorado Business Innovation Challenge—that will give financial incentives to the technology community to build web and mobile applications that use state and other data to solve existing business challenges.

The data platform is akin to an information clearing house. It will make data sources currently dispersed over multiple government departments and agencies accessible in a common location. 
This platform will offer Colorado businesses unprecedented access to public data that is validated and relevant to short and long-term needs. Besides enhancing businesses’ access to state data, the BIC will also contribute to economic growth. The creation of the BIC will make data available to all Colorado businesses at no additional cost. Currently only large entities with the time, staff, and budget to engage in detailed statistical analysis can use these data sets. Providing this data to every type and size business in Colorado provides a unique opportunity to contribute to economic development. The BIC will nurture key industry networks and lay the foundation for a digital infrastructure that will continue to expand and improve over time.

The Colorado Business Innovation Challenge is an innovative way to create solutions and ensure the BIC is useful to Colorado businesses.

Simply making the data available is insufficient to most business owners. To truly help the vast majority of businesses—especially small businesses—tools must be developed to present the data in a useful and consumable form. Normally government agencies develop tools to fill this information vacuum, but historically the government has not been successful developing highly useful and effective tools. A new approach is needed—that approach is the Colorado Business Innovation Challenge.

Modeled after a “civ apps” challenge that has been run in multiple cities across the United States and internationally, the Challenge presents the software development community with problem 
questions and then asks that community to create possible solutions. At the end of the challenge, the Secretary of State will license the most innovative and implementable web or mobile application. The best design will receive a contract with the Secretary of State to make the application available to the public on the Business Intelligence Center platform. The Department will also pursue partnerships with the Colorado technology and startup industry to provide additional incentives, such as mentoring, hosting, and office space to the Challenge winners. The long-term intent of the program is to not only create an environment for fostering community involvement through the Challenge, but to develop sustainable tools that are  developed in the Challenge.