Archive for the ‘Continuous Delivery’ Category

Lean-Agile Mindset – The Secret Sauce

Lesson Learned: Fund Agile Value Streams instead of Projects, for High Performance

For 12 years I’ve led organizations structured with Scrum/Kanban product delivery teams, shared services teams, and cross-functional roles embedded in these teams. Guiding and encouraging these teams to be effective in their iterations and their evolution into continuous delivery pipelines results in vast improvements over waterfall or some variant of “scrumerfall” SDLC patterns. However effective these teams become in the SCRUM/KANBAN mechanics, the company can only be high performance when work is funded through the value stream and not by projects.

Over the last year I’ve been working as a SAFe(R) (Scaled Agile Framework) solutions architect for cPrime.  Participating in the SAFe Agilist certification training I experienced a transformation in my thinking that emphasizes managing lean budgets to fund work. I’ve had the opportunity to work in several fortune 500 companies both domestically and abroad, and reflected on my last several years in contributing to scaling our agile organization at Constant Contact as a Director of Quality Engineering. The most striking realization that was revealed to me is that no matter how hard you try to get to a high performing Agile company (DevOps CI/CD pipelines), if the corporate financial structure does not change to Lean-Agile approaches then the company will never get there.

Lean-Agile leaders all support the notion of Lean-Agile Mindset that includes funding work through value streams (or equivalent constructs) where the work is brought to the teams, rather than the traditional project management approach of funding projects and bringing the teams to the project.

  • Funding Value Streams requires the company to recognize the teams build a coordinated pipeline of capability (flow) to deliver value to the customer in a predictable way (teams of teams). Removing traditional delays and overhead enables lean prioritization of work to be delivered to the customer in small batches with regular short feedback loops to validate the value and shape future work.
  • Funding Traditional Projects requires phases and gates (start and stop) pattern of delays to prepare and approve milestones along the way, building up delay in value and longer feedback loops. This also results in rework that adds further delay in the project. This is an anti-pattern to Lean-Agile and stifles momentum on multiple levels, introducing costs as delays.

A realization that emerged from training and I’ve been able to reflect on, is that these approaches address very different parts of the iron triangle.

  • Funding Value Streams fixes the TIME corner of the iron triangle, where if QUALITY remains fixed then the COST corner has to give.
  • Funding Traditional Projects fixes the COST corner of the iron triangle, where if QUALITY remains fixed then the TIME corner has to give.

Agile hypothesis-driven business development feeds a funnel of small changes and fast feedback loops to the business. This approach enables the company to develop solutions to customer needs incrementally and adjust along the way.

  • Funding Value Streams enables forming an hypothesis for adding value, sizing the effort to prove the hypothesis, and sampling the hypothesis with customers along the way.
  • Funding Traditional Projects assume a model of completing all the work to prove the hypothesis before delivering the solution to the customer for feedback.

Further, the company needs to shift how it views governance in this new world. The management constraints shift from project-progress based to value-delivered based, and therefore the KPI’s (key performance indicators) for measuring success of the business shift as well. The traditional PMO team transforms to an “Agile PMO team” that drives this new governance model.

  • Funding Value Streams KPI metric examples
    • Program Increment Objectives – Business  Value (plan vs. actual)
    • Predictability of velocity and volatility as points completed in each sprint
    • Throughput (time to deliver value from concept to customer use)
    • Hypothesis tested vs. hypothesis failed over time
  • Funding Traditional Projects KPI metric examples
    • Cost Performance Index and Cost Variance (on-time and within budget)
    • Missed milestones and % tasks complete
    • Resource utilization
    • % cancelled projects

These concepts are very important to consider before starting on the Enterprise journey of scaling agile. It means all the executive leaders of the company need to go through this training to realize this shift has to take place. These executive leaders then form new strategic themes and initiatives that are the basis for funding these value streams of agile teams. When this happens, then the company can truly transform to a Lean-Agile organization. Only then can the company strive to high performance.


Trust Your Instruments

February 4, 2017 Leave a comment

Lesson Learned: Calibrate, monitor, and trust your instruments to keep on track.

I love to hear and tell stories in illustrating lessons learned. They really convey the emotional impact of the lesson at the time is was learned. This is a tale of two opposing true stories related to small craft navigation that actually happened to me. They take place a few years apart but have a number if similarities that make the point of the lesson learned.

Foggy Fail

In the summer of 1996 I was invited to on an night-time striper fishing trip inside the mouth of the Merrimack River. The skipper was the bother of a colleague, and he had a few friends and relatives on the trip. This was a beautiful 36′ twin-screw motor yacht that was only a year old. It was a very calm serene evening trip destined to anchor in the area inside the Ben Butler’s Toothpick rocks opposite Joppa Flats in Newburyport, MA. We dropped anchor in a two-point moor to keep our position fixed. I don’t recall what we were using as bait that night, but I know it was not artificial lures. We fished well into the night with little success, and no keepers, but it was a fun night. Shortly after midnight the fog rolled in quickly from the sea, engulfing the boat. It was a weeknight, getting late, and a bit cooler. So, we pulled up anchor and attempted to head back up river to the slip.

marine-radar-scopeThis boat was equipped with radar and could see the outline of the mainland mass and other larger objects, but couldn’t see the sandbars or markers on the radar, and we couldn’t see the shore. The tide was low and going lower, but could see and sense the flow of the river. The skipper pulled up anchor and started heading upriver. We could now see the first marker and it looked like we were heading in the right direction. A little further and we saw some other boats anchored that we had to move around. And then the boat touched a sandbar. The skipper motored over that one and back into the channel. We thought things were going well, but the appearance of the channel didn’t match the radar. The skipper started to correct to get back on track with the radar, but had to motor over another sandbar. This didn’t make sense. We should be on track and in the main channel, but as we moved forward we keep getting off course. The skipper debated backtracking downriver to get the channel and radar back in sync before going upriver further, but decided his instinct was better than the instruments. Big mistake. As it turns out we were getting further up a tidal channel in Joppa Flats with the tide going out and ran hard aground on the sand flats. We hit hard and you just know there was damage to the underside. The skipper radioed for the tow boat to come help. It was an off-hour call so it would take time for them to get there. Before we know it the boat listed to the side and we were high and dry on the sand. The tow boat could not help except to taxi the guests back to the dock. The skipper had to wait until dawn for the fog to lift and the tide to come back in and float him of. It cost the skipper several thousands of dollars that night in repairs and the tow back to the dock.

Foggy Success

In the summer of 2002 I took my Dad out for a ride in my new 21′ cuddy cabin I/O boat to the Isles of Shoals island of Portsmouth NH. It was a calm Saturday morning early in the season when the water was still a bit cold. I set the Isle of Shoals weigh-point in my dash-mounted GPS and we headed down river. It was nice and sunny, and we were up on a nice plane at 22 knots. We left the mouth of the Merrimack and veered off towards the Isle of Shoals. About 10 minutes into the ride we noticed what looked like fog on the horizon. It was moving towards us at a faster rate than I thought and I could feel a westerly breeze picking up. As the fog approached I noticed my Dad looking around my dashboard curiously. My Dad is an old-school electrical engineer, who was a master at the slide rule, map calipers and parallels, and calibrating an oil-filled compass. So I had to ask him what he was looking for. He ask where my compass is. I pointed down to my foot locker and said it was in there. He looked up at me shocked as the fog began to engulf us and asked how the hell are we going to navigate now? I dropped off the plane to about 8 knots and continued on track.

p_6875_garmin-gps128I pointed to the GPS on the dashboard and said I’m navigating from GPS. It tells me direction, constantly correcting for the westerly breeze nudging us to port. I told him I know how fast we are going, where the nun buoy at the entrance to the harbor is that we are targeting, and how long it is going to take us as this rate. He said oh, and what if that fails? I pulled out my backup waterproof handheld GPS in my pocket with fresh batteries and said “then we use this.” He looked at me with guarded approval and said “ok, if you say so.” Clearly my Dad had not used GPS for navigation before. At this point we had about 50′ of visibility. As we approached the targeted buoy, I slowed right down to a idle and said look off the bow, we should see the buoy in a few seconds. The red nun then popped out of the fog. And my Dad said “son of a gun, it worked!” My Dad and I used very different tools to navigate in nautical waters, but we each trusted our instruments and were able to keep on track with where we are going and when we will get there, even when we can’t visually see the target along the way.


Both these stories are memorable. The both share the lesson that you need to have good instruments, that give you the visibility you need to keep on track, and that you trust the instruments to guide you when you can’t see the target.

The same can be applied to the SaaS industry. We have many ways to measure and calibrate our instruments for applications, their containers and infrastructure and their tests. We must choose our measurement tools wisely, and calibrate, monitor, and trust your instruments to keep on track.


SaaS Deployment Fail

October 13, 2013 Leave a comment
Push Button Deploy

Remove the human factor from your deployments to avoid mistakes.

Lesson Learned: Automate your entire deployment pipeline and don’t celebrate until you are done.

Most SaaS (software as a service) companies carefully plan and orchestrate deployments as a core competency. Many veterans of these deployments have learned to be good at it through experiencing failures and learning what not to do. One of the greatest learning opportunities is when things go terribly wrong and it takes heroics to correct. This story is one of those experiences.

In 2005 I was the Director of Quality at Convoq, a video conference start-up. We build web-based and desktop video conference tools that enabled applications like to evoke ad hoc or scheduled video conferences (Convoq ASAP Pro). The application was build upon the Adobe Flash Media Server. Customer accounts, their contacts, and conference history was stored in a relational database. We used physical hardware built from ghost images to assure our servers were carefully replicated for high availability.

We carefully planned and iterated on an instance of the Deployment Document for each release. Although we continued to add automated scripting for deployments, we still had to manually start the scripts and we had to add in all the verification points along the way. We also had a final Deployment Document sign-off ceremony prior to commencing any release. We thought we were pretty good at this pattern. During deployments a member from each group and members from IS would assemble in the conference room to work through the deployment document procedure together. The procedure included putting up a maintenance page during an outage, and we worked at making this outage as short a window as possible. We planned our releases to begin at 5pm Wednesdays, since Wednesday evenings seem to be less impact to customers on the west coast, it gave us all night to complete the deployment if things went wrong, and we had the next day with a full engineering staff to address any problems that might result from the deployment the night before. On planned major release days, we brought in beer to celebrate the completion of a release.

One planned release, we began as we normally do with both email and in-product notification of a scheduled release. There was a short outage window expected with this release. It should be very routine. Here is how it went as I recall it…

  • 5 pm ET: We assembled in the conference room as planned and proceeded to execute pre-deployment steps, including putting up the maintenance page. Each step was called out verbally when started and finished, for both changes and verification. One of the changes was a series of SQL statements that would update the schema and add related tables. Order of changes and completing verification of a change must precede the next change. This included migrating some data to new tables and updating the index.
  • 6 pm ET: As we proceeded to execute through the initial changes everything was going well. This seemed routine for us and the were a bit punchy, joking about customers, and having a great time. We were more than half-way through the release.
  • 6:30 pm ET: The last part is a piece of cake and we expected to complete by 7PM ET. We were feeling pretty good about this release and ready to celebrate. So, we broke out the beer. Boy that first gulp tasted good. Things were still going fine as we get down to final testing of these changes. Then, we noticed the contacts for one customer were appearing under a different customer. Really? How can that happen?
  • 7PM ET: The tone of the room starts to change. We check other customer data and find the same thing. We start searching through changes and database queries to figure out what happened. Apparently a database change was made before a prior database change completed. We lost track of verifying start and end to each step and got out of order. I recall that a change was made to correct the problem and made it worse. Agh, the beer must have clouded our minds and we messed up. All the beer went into the trash. We should not be celebrating this early.
  • 9 pm ET: We are still trying to understand the impact of the problem. Phone calls go out to the database experts to get them looking at the situation. We even had a couple engineers come into the office. We also were trying to replicate the problem in one of our test environments. We call spouses to indicate this will be a late night or all-nighter.
  • 11 pm ET: We are clearer about the issue now and believe we know how to correct it. I make a statement that “we just have to be back up by dawn.” 7AM ET is when our published SLA (service level agreement) with indicates when we will complete any maintenance window by this time, and shortly afterwards the CEO arrives each morning.
  • 1 am ET: We made progress with database corrections. However we still have a data problem that needs correcting.
  • 3 am ET: The coffee is not working to keep me awake. I do some pushups on the floor to wake me up and resume verifying fixes.
  • 5 am ET: We believe we have it all solved, but not ready to turn on traffic yet. It’s still dark out and the birds aren’t singing yet.
  • 6:45 am ET: We enable traffic again. Everything looks good. We keep verifying live data and watching logs to see that all new activity looks right.
  • 7:20 am ET: The CEO walks in the office. I’m usually in the office by then, so he doesn’t yet see anything out of the ordinary. He walks by my cube and asks how the release is doing. I told him everything is working well. He said “great” and proceeds to walk towards his office. He stops, looks back at me, and asks if those are the same clothes I had on the day before and forgot to shave, with a smirk on his face. I told him he was right, and then he noticed more folks in the office than usual at this hour. I then had to tell him we had some problems with the deployment that required us to work through the night, but we were live before dawn and met our SLA. He laughs and then asks me to come to his office to explain.

I don’t believe I mentioned the beer in my explanation. I did mention that we would be much more careful about keeping the deploy steps in order next time and automating as much as we could. It was the human element that got in the way of a successfully executed release. Most of our customers will never know there was any problem, and our SLA was met. We came dangerously close to having a far bigger impact to the field. This experience convinced me to strive for automating the deployment pipeline end to end, including validation between steps.

%d bloggers like this: