The post The Journey to Success: A CIO’s Perspective on Innovation and Growth appeared first on Steampunk.

Steampunk’s Design Intelligence® Framework is an integrated approach for delivering solutions that incorporate Human-Centered Design into all aspects of the development process. While we apply the framework regularly for our clients, what many people don’t know is that we’ve also been applying the framework internally to re-engineer our internal business operations. The results have been nothing less than extraordinary. In short, we’ve developed business processes that are more aligned with our culture and values, produced higher employee satisfaction, and increased transparency and efficiency.

Steampunk’s recruiting and onboarding process is a great example. A cross-functional team of Service Designers assessed our current process and provided several recommendations for improvement. Highlights of their findings are below:

• Managers were asked for duplicative information already provided during the recruiting and onboarding process.
• New employees were overwhelmed with the amount of information provided in the first week; they wanted more time to complete onboarding paperwork and training, allowing them to become more attuned to their new project and clients.
• New employees were craving deeper insights into company projects and wanted to learn more about their peers.

In the CIO team, we use Agile to manage our work. We broke the findings into user stories and began working across the company to research improvements and implement changes.  We’ve made hundreds of improvements to the process, but some of the highlights are below:

• Information is collected once. Information from our Applicant Tracking System auto-populates our Service Desk and HR systems. Finance, HR, and Marketing have access to consolidated data ensuring candidates and managers are not asked for redundant information.
• More time for onboarding. HR Paperwork and IT Training is now spread over the first month to ensure employees have adequate time to focus on absorbing the material, and to ensure they can also spend time getting up to speed on their new projects. Employees are assigned PunkPals to facilitate acclimation.
• Improving Collaboration. Employees are automatically added to Slack channels and distribution groups based on their Project, Practice, Sector, and Portfolio. A newly launched Operations portal provides a one-stop location for learning about projects, personas, and technologies used across the company. We’ve also automated provisioning of IT systems so that new employees have the tools and access they need on day 1.

Applying Steampunk’s Design Intelligence Framework has been a great experience and we’re looking forward to evolving the enterprise to continue to produce a better experience for our employees and partners. #People@theCore

The post Eating our own dog food – Applying Design Intelligence® to internal operations appeared first on Steampunk.

The Answer is Steampunk Design Intelligence^®

As I mentioned above, it’s not enough to have the best tools. In my experience in and out of uniform, even the most technical of problems rarely have technological or tool-based causes at the root. Much more commonly we as human beings struggle with problems of poor communication, overlooked requirements, lack of buy-in, mismatched expectations, and under-adoption. As rightfully proud as we all can be for building and maintaining the most powerful and well-equipped military force in human history when we think of our community’s greatest (and sometimes most comical) failures it’s rarely a material failure, a poor tool, or a misapplied technology which are to blame. Those things are symptoms to be sure, but when we dive deeper we go back to those human themes. These themes can’t be engineered out, although many have tried. Instead, we must turn to Steampunk Design Intelligence^® powered by design thinking to be our guide.

Design Intelligence^® is an approach to problem-solving which ensures the human-impacted by the design is primary – and that the influences and constraints upon that human are considered and mitigated. What results is a solution architecture which is not just ready to be built, people are excited to adopt it.

So how is that different from traditional requirements gathering? Isn’t that process supposed to include all of those variables? Well, yes, it should, but it rarely does. Traditional requirements gathering is very effective at documenting parts of the puzzle, but it routinely fails to compensate for vital variables that will impact the overall success of the project as it relates to the human’s ability to accomplish their mission, not just contractual success.

In our experience, all too often the design capabilities and resources offered to the Defense Department (if, in fact, they’re even a part of the solution) are stove-piped from the more tactical technology integration, application development, and infrastructure engineering efforts. Clients are brought into a slick customer visit center to participate in design workshops that paint a great vision, but that vision falls apart in execution because the staff doing the implementation wasn’t integrated with the design experts who helped to define the original vision with the client.

That’s why our Design Intelligence^® approach is structured to ensure we never lose the value of Design and HCD as an iterative process executed by an integrated team from end to end. For us, it’s not enough to engage only development or technical teams in the implementation, or conversely to leave them out of the initial design phases. We know that by efficiently engaging critical stakeholders and experts who represent requirements across the business, security domain, data environment, and technology organization throughout the project, we are going to be much more successful in creating and implementing solutions that are practical and will be accepted by the actual mission users. Furthermore, we make sure we understand the external factors that are driving both the opportunities and constraints for our Defense customers. We go so far as to engage experts from academia and other industries as part of our virtual team to offer our clients emerging views on commercially proven innovation, political headwinds, and opportunities, and financial management strategies to ensure the best return on investment. This is the integration that ensures what we build drives real Mission Impact.

Design Intelligence^® in Action

Now that we’ve explored the approach Steampunk brings to the fight, let’s take a look at tactical execution in that model. If Design Intelligence^® sounds squishy, it isn’t! On the contrary, it’s the engine we can use to drive better results to the tactical edge with much more speed and “quality the first time” than traditional approaches.

The post The Steampunk “How” appeared first on Steampunk.

So why “Steampunk”?

Part of the fun of a new enterprise is a chance to truly wipe the slate and be deliberate about those cultural questions I posed above. As I discussed in the last article, Built Differently, Steampunk is about putting people at the core, so when it was time to design the ship that would carry us on our journey we did what we encourage our clients to do: engage in a Steampunk Design Intelligence^® session to get to the root of our challenge. We talked about the things that made this group unique, what motivates us, lessons learned from our past experiences to perform better for our customers, and the specific way we want to innovate in the technology space. We explored themes like:

• Disruptive creativity that breaks paradigms
• Inviting voices with answers outside the mainstream
• The confluence of humans and technology, and maybe most importantly
• How would today be different had technological solutions come sooner

These themes evoked imagery of people and technology creating new things together: distilleries, factories, foundries, and artists’ studios. We tried to think of the kinds of spaces where our brand of technological creativity would thrive, places of industrial design built for collaboration. Steampunk. That was the word that kept surfacing to describe the tone and culture we were looking for.

For those who don’t know, Steampunk is a rich genre of science fiction and science fantasy that explores an alternative history where steam-powered technology melded with 19th century aesthetic to imagine the amazing lives people could lead had technology come differently… and sooner. It’s a genre and a subculture that attracts creative minds, celebrates the fantastic, and defines itself by breaking barriers, scientific or otherwise; think Mary Shelley, Jules Verne, and H.G. Wells.

“Steampunk is a genre that imagines how different the past might have been… had the future come earlier”

I hate to disappoint you, but you won’t see us wearing mechanical goggles or driving steam-powered airships… at least I don’t think so, and it’s not our intent to copy or ‘kitschify’ the wider Steampunk community. But we absolutely want to draw on its themes for inspiration, and to use it as a rallying cry to draw us back to our core values: Put People at the Core, Thrive Being Uncomfortable, Set the Pace, and Empower Our Community. All while bringing disruptive technologies like advanced Cybersecurity, Data Exploitation, DevSecOps, and Platform Development to bear with a human-centered approach.

As a companion to this week’s discussion of the Steampunk name and how it helps us communicate our core values and approach, I invite you to check out this piece by our Chief Technology Officer, Sean Dillon: DOD Identifies Fake Agile, Changes the Game.  It’s a reaction to the Forbes article about DoD “Fake Agile” and it’s a great way to think about operationalizing the approach and culture wrapped up in the Steampunk way of doing business.

The post What’s in a Name? appeared first on Steampunk.

If there are genuine bad actors (the “beltway bandits” of folklore fame) I’ve never met them. The vast majority of those I work with and compete against are patriots who want to serve the Department of Defense the very best they can. On the other side of the acquisition fence, I’ve never met a Government leader who didn’t want the best product or service for the best value. But there are externalities and variables beyond the control of these individual good actors that can cause our best intentions to fizzle, and the Warfighter to end up with less than they deserve.

Over the next few weeks and months, I’d like to start a conversation here about how we address those challenges. In many ways, solving the hard problems and enabling the missions we ask the Department of Defense to execute must be a partnership – no entity can do it alone. Companies like Steampunk must be a willing partner with other industry players, and no successful program operates without a hand-in-glove relationship with the Government.

So, let’s get started! Just what is Steampunk? Steampunk was founded with a very specific mission in mind: how do we help the Government transform, with the help of cutting edge technologies all while keeping people at the core. Putting people at the core means more than just “engaging stakeholders” – it’s an entire paradigm shift. Whether we’re developing software enabling the mission, or securing a network, Steampunk’s emphasis on Design Intelligence^® encourages engagement with the end mission implementer – which may or may not be the “user” in the traditional software sense of the word. Working on a program to improve Defense Health support to families? Let’s talk to those families. Let’s understand the requirements behind the requirements. By keeping the mission and the Warfighter in the center of every process, we can go beyond “contractual compliance” and can start delighting Soldiers, Sailors, Airmen and Marines with results.

Doesn’t everyone want this? How is Steampunk different?

But this all sounds like Mom and Apple Pie, right? Is there an industry partner out there who would disagree? Probably not (I hope not!), so how are we different? Steampunk is built structurally to take risk and be responsive to our Defense customers in a way that is genuinely unique. By being employee owned, Steampunk can take the ‘long view’ – we’re here to solve problems, not fill cubes. Part of being nimble means being flexible to how and when our Defense partners need to acquire services. Without pressure from public investors, Steampunk can stop worrying about Wall Street quarterly reports and start worrying about Pentagon daily briefings. Being nimble also means taking risk. Too many of our friends are pushing the Sisyphean boulder up the mountain that is internal corporate approval only to have it roll down stamped “too risky.” We exist to take on risk. We exist to support an enterprise which defends the Nation. To take risk off their plate is the greatest professional honor we can ask for.

Next time I’d like to share some thoughts around the Agile transformation in Government – how much of it passed us by in Defense, and the opportunities we have to really get it right. Many thanks from those of us at Steampunk to all of those in our Defense community, both in Government and in Industry working every day to keep our men and women safe, secure, and lethal.

Stay tuned for Steampunk’s ability to help DoD battle the “fake agile” bug – as well as more on the Steampunk brand. What’s in a name anyway?

The post Built Differently appeared first on Steampunk.

The non-technical elevator pitch for Agile development relies in large part on the perceived (and real) shortfalls associated with doing software application development using waterfall techniques. Broadly speaking, the concept of waterfall development has its genesis in manufacturing, and in the context of the federal government, that primarily means building equipment for the military. When you build equipment, you need to have the specifications set before you start the work.  For instance, if you are building a submarine, you better have the submarine fully spec’d out before you start building it.   If two of the hundreds of thousands of components of a submarine don’t fit, it sinks. While you can ‘refit’ your submarine from time to time, fundamentally the submarine remains true to the specifications that were set out before the first build step.  Rigidity in the specifications and the build is the point of the waterfall approach.

However, by definition, lifting and dropping a waterfall approach into complex software development projects results in a fixed set of deliverables. Given the pace of change in the IT world, software deliverables defined three years ago are often technically obsolete by the time they are delivered, and likely have not kept pace with the evolution of the government’s business requirements in the time between the flash of requirements being defined and the bang of delivery to the actual end users.

To the rescue came Agile development. Designed specifically to enable requirements to evolve with the actual development, Agile allows and encourages refinements in project requirements and priorities to adapt to new mission needs, the newest technologies available and evolving environmental factors.

Sounds good right? Done right, it is However, there is an inherent conflict between a certain type of an ever more popular federal contract structure and Agile:  Firm Fixed Price contracts.

Put simply, a firm fixed price (FFP) contract is what it sounds like: for a set price a contractor will deliver a defined set of deliverables. The government can generally rely on the fact that it will get those deliverables at a price defined upfront as opposed to a time and materials (T&M) contract which, though providing more flexibility, ultimately only guarantees the customer that they will get a discrete level of effort, as opposed to a discrete set of outcomes.

The challenge with FFP is that in order for a contractor to price a project, the government’s requirements must be clear and explicit upfront. When Agile is introduced into this scenario, there is an inherent conflict between requirements defined upfront to enable fixed price contracting and one of the main benefits of Agile: ongoing adjustments through the releases and sprints and Agile best practices to modify requirements and priorities as needed or desired in light of emerging needs.  Further complications ensue with the concept of short term and frequent requirements refinement. Often in the context of two week sprints, during which failing fast can sometimes be a virtue, the inability of the formal contracting process to keep up with the evolving nature of requirements in the context of Agile delivery can be a real conflict.

What to do? There are lot of FFP Agile application development contracts out there, aren’t there?   There are indeed, and there are a number of ways to square the circle between Agile and FFP contracting. Perhaps the most popular approach is to tie the fixed price obligation to Agile capacity or team output. In the case of capacity, the fixed price might be for a discrete number of sprint teams delivering a certain number of sprints over a defined period of time. For output, the contractor may quote a fixed price for the delivery of a discrete number of function points or story points (both of which are essentially project defined incremental software delivery milestones).

Problem solved? To some degree but not entirely. Unfortunately, the above solutions are often viewed as the end solution to the conflict between FFP and Agile, when in fact those solution are only an interim step, and sometimes they present another challenge. In the Agile capacity model, fixing the team size or composition, as many agencies have in recent Agile FFP procurements, may or may not be the right solution for a given contractor. Those that are more disciplined and efficient may, in fact, be able to propose a team composition or team size that would be more cost effective or more productive.  So, allowing some flexibility in team size is often a good option that benefits the government. In the latter case with output based on story points, the strategy reveals a misconception about Agile that all story points are equal. Fundamentally, story point estimation is part art and part science – and will differ from team to team within an Agile program, let alone across programs.  Thus, each strategy to pre-define the team sizes or output may limit the contractors from providing the best value solution in a competitive procurement.

The last step in solving these contradictions is one that only disciplined Agile contractors adhere to. Across the Federal space, there is unfortunately all too often a lack of that discipline.

Regardless of contract type, almost all government contracts will have the government’s requirements  laid out in the award documentation. The variability in how specific those requirements will be set forth is wide (SOW vs SOO, for instance), but regardless, the award document will be a key artifact during the course of the contract, and that  artifact in most circumstances will not change.

However, we know that by definition the requirements in an Agile delivery project will change. Therefore, there is a real risk, particularly if the award document is very specific as to requirements, that at the end of the Agile project you will have deliverables that don’t match with the requirements set forth in the award documentation. While a contractor may have met its output or capacity obligations, if the requirements set forth in the contract aren’t met, your customer: 1) may be under potential duress if there is an audit of the final deliverables and the contractual requirements; and/or 2) may not have what they originally said they needed (regardless of what they need today); and/or 3) may say the requirements were not hit and require re-work at the contractor’s expense. While the associated project leader may have great relationships with their mission sponsor and/or their COR, how often do those folks transition to new positions during the course of a three or five year engagement? If a new sponsor comes in, the ‘understanding’ as to current requirements the contractor may have had with the previous regime may not convey to the new sponsor, leaving the contractor holding the bag.

This is where disciplined Agile delivery practices come into play. While important in the context of any Agile delivery, this discipline is particularly key for FFP. Specifically, at the conclusion of each sprint, the government and the contractor go through a documentation process, identifying myriad factors such as team velocities and the like, but also two other key things:  1) memorializing that both the government and the contractor signed off on the current sprint deliverables; and 2) identifying the development focus for the next sprint. In both cases, it is absolutely crucial to document both of these aspects of the sprint process, looking at the evolution of the requirement in both the rearview mirror and prospectively. In that way, through the inherent Agile process, a contractor creates a living and evolving set of documented requirements that, crucially, establishes that what was being delivered is in fact what was directed. Documentation of this type can seem a bit tedious and must be coordinated with the contracting officer, but having seen both disciplined documented Agile delivery as well as its evil twin, in this case an ounce of prevention is absolutely worth a pound of cure.

The post “Fixed” Agile in Government Contracting appeared first on Steampunk.

 In the excitement to bring Agile to the DoD, many service providers are claiming to use Agile when in fact, they are renaming old techniques to something that sounds like Agile but fails to deliver the value. Because what is at stake is so significant to their overall mission, the DoD has created a guide to help their teams “detect Agile BS.” The intention with the guide is to assist in making good decisions internally related to programs as well as assisting in the process of hiring DoD contractors.  

For those of us at Steampunk that have lived this story many times over, we’re excited to see this kind of motivation by DoD to arm their teams with the intelligence they need to recognize the enemy. In this post we wanted to dig into the article a little further and introduce some of the techniques we use at Steampunk to not only detect the Agile BS, but get it back on track to reap the benefits that Agile can provide.  

Government Identifying as Not-So-Agile 

Throughout Denning’s article, the points he makes lead the reader on a journey to explain how modern DoD practices are changing to combat this challenge. There are now DoD guides that ask the questions necessary to determine whether an organization is truly practicing Agile or if they’re faking it. There are common patterns you can enter into a BS meter, and it’s not all that challenging to find those that may be well intended, but a lack of Agile knowledge has them falling back to traditional approaches to project management. 

For those of us at Steampunk, this is a very refreshing change of pace. For years, we worked with government organizations that either didn’t want to embrace Agile at all, or when they did, is was good enough to take traditional processes and label them as Agile. Daily status meetings were scrums, monthly status reports were sprint reviews, and product owners didn’t really know the users and approached the job as a plus one responsibility.  

We are excited to have inspired and led many of our clients through Agile transformations, but the work is far from over. The difference here, however, is now we have an opportunity to help clients that recognize the need to embrace something new, something unknown, and something that can significantly increase their chance for mission success. 

We Found Agile BS, Now What? 

The article talks to the various guides and guidelines provided by DoD to help identify Agile BS. In the guides, there are questions that speak to how software should be delivered to users at every iteration, how feedback loops should work on the team, and how that feedback should be incorporated into the project’s requirements. In the guide there are numerous questions for programming teams, program management offices, customers and users, and program leadership that should lead the interviewer to whether or not a program is actually using Agile. 

The challenge with this overall premise is that the guide relies upon the person asking the questions actually understands Agile enough to effectively evaluate the answers. Some of the questions get sample answers that indicate Agile or BS, but this leaves the reader wondering where to begin when they want to remediate the non-Agile approach. 

A New Command & Control System 

Part of the article speaks to General Stanley McChrystal’s book, Team of Teams: New Rules of Engagement for a Complex World, and how his approach to leading the Joint Task Force in Iraqhad to change to meet the innovative nature of an adversary not willing to fight by the rules.Some of McChrystal’s discoveries through this experience related very closely to how Agile can be leveraged by large teams: bringing together teams into a common physical space, open communications amongst the teams for common situational awareness, and pushing down decisions to the lowest level rather than forcing a traditional command and control model where decisions are made (at some point in the future) by senior members of the team. 

McChrystal’s observations from his experience in Iraq is a good example of how long-standingprocesses  will not continue to be effective and reinforces the need for Agile processes throughout DoD.  

Users at the Core 

One of the most encouraging aspects of the article was the focus on communicating with users for continuous feedback and requirements gathering. The transformation from waterfall to Agile has a significant impact on the quality of the project being delivered, a significant increase in the transparency of the work being done, and precise predictability of when requirements can be met relative to the team performing the work. 

The upside of this transformation is undeniable, but as with all disciplines there’s another level of Agile expertise that’s worth mentioning early on. Some of the questions in the article and DoD guides allude to the interaction with users. It is essential to place a primary importance onputting the users at the core of a project. Without this focus on the actual users, there is a tendency for appointed leaders, contracting officers, or at times even the contracted development team to infer what the requirements should be or how they should be interpreted, resulting in extreme disappointment or completely missed expectations. 

We have witnessed this trend in even our most promising of clients that embrace Agile. The users these systems served get left out of the process, and ultimately, they are the ones that can make the biggest impact on the outcome of the effort. Due to this, Steampunk placesHuman-Centered-Design (HCD) firmly in the middle of our Agile and DevSecOps processes, ensuring the users’ needs are identified, their concerns are being addressed, and they are first-class citizens throughout the innovative solution development process our teams bring to our clients. 

Summary 

Steampunk is excited to see this kind of momentum for Agile in the government. Having seen the reluctant adoption of Agile over many years with our clients, the tools and techniques DoD are providing offer a great way for mission owners, program managers, contracts managers and government leaders to start to separate the good from the bad and fully utilize Agile processes to bring about more effectiveness to the government.  

Over the years, our approach to Agile has helped our clients put their users and mission at the core, resulting in much stronger, more durable solutions. We have pointed out the pitfalls and traps, and helped countless clients realize the benefits that results from true Agile adoption.  

I applaud the Department of Defense for leaning in on this topic and working hard to help their organizations to optimize their efforts to secure the nation and protect our warfighters. If the DoD, or any government organization for that matter starts asking the questions and hears answers that sound like Agile BS, we’re here to help. 

The post DoD Identifies Fake Agile, Changes the Game appeared first on Steampunk.