Tag Archives: Agile transformation

The 7 Habits of Highly Effective Agile Transformation: Habit 5 – Seek First To Understand, Then To Be Understood

We are 4 down and 3 to go in our exploration of Stephen R. Covey’s book, The 7 Habits of Highly Effective People, with regard to effective Agile Transformation. Our focus this time is Habit 5 – Seek First To Understand, Then To Be Understood. Quite frankly, Habit 5 is the answer to Habit 4 – Think Win/Win or rather, seeking first to understand makes Win/Win possible.   

Habit 5 centers around the highest form of listening, what is referred to as “empathic listening.” With this Habit, Covey challenges us to develop the powerful skill of empathetic listening to first diagnose, seek to deeply understand, before prescribing a fix to the problem.   

READ ON


The 7 Habits of Highly Effective Agile Transformation: Habit 4 – Think Win-Win

We are at the midway point in our Agile Transformation-focused exploration of Stephen R. Covey’s “The 7 Habits of Highly Effective People” with Habit 4 – Think Win/Win. I’m sure we’ve all said it in business and even relationships, but how does Covey intend it towards being highly effective and what does it mean to an Agile Transformation?

Before we explore the answer to that question, it seems appropriate for a quick refresher on the first three habits. Habit 1 – Be Proactive, and Habit 2 – Begin With The End In Mind ultimately enable Habit 3 – Put First Things First. In terms of what we’re here to talk about, an organization that is proactive (Habit 1) with an end state vision (Habit 2) and realizes it through a focus on what’s most important (Habit 3), is well on their way towards effective Agile Transformation. With that, let’s now consider Habit 4 – Think Win/Win.

READ ON


The 7 Habits of Highly Effective Agile Transformation: Habit 3 – Put First Things First

Last time we explored Habit 2 – Begin With The End In Mind of Stephen R. Covey’s “The 7 Habits of Highly Effective People” as it relates to Agile Transformation.  With Habit 2, we concluded that it’s essential for an organization to begin with the end in mind, their end state vision, for an Agile Transformation to be successful and that they must be proactive (Habit 1) in support of that. This time we’ll explore Habit 3 – Put First Things First for which Covey considers the fulfillment of Habits 1 and 2. 

READ ON


The 7 Habits of Highly Effective Agile Transformation: Habit 2 – Begin With The End In Mind

In the first blog in this series, we explored Habit 1 – Be Proactive of Stephen R. Covey’s The 7 Habits of Highly Effective People. We concluded that a company’s choice to pursue an Agile Transformation is a proactive response to their circumstances that powerfully affects their effectiveness and ultimately their success. Continuing on with the exploration of how the 7 Habits apply to Agile Transformation, let’s take a look at Habit 2 – Begin With The End In Mind.

READ ON


The 7 Habits of Highly Effective Agile Transformation: Habit 1 – Be Proactive

So, I’ve done a thing and made a commitment to a new blog series on the LeadingAgile blog. Inspired by Stephen R. Covey’s The 7 Habits of Highly Effective People, I’ll be exploring The 7 Habits of Highly Effective Agile Transformation. Check out the first blog post in the series on Habit 1: Be Proactive.

READ ON


Happy 2nd Agile Anniversary, Catalina

BabyYodaTwo years ago this month Catalina went full bore, head first into Agile, applying the Scrum methodology, to deliver and execute on the top priorities of the company.  Now, two years later, we continue to embrace and uphold the Agile values and principles.

We’ve made it all the way to Sprint 53, but who’s counting?  In fact, you might think of us as Baby Yoda right now.  In the past two years, Catalina has delivered thousands of valuable stories to our stakeholders including retailers, CPGs, and corporate.  We continue to scale Agile up and across our enterprise.  And, we’ve got our senior leadership team applying Kanban at the portfolio level to manage Portfolio Epics as part of our Agile Portfolio Management process.

While we are at the end of our transformation, we are only at the beginning of our journey.  As we begin to roll (or shall we say sprint) into year 3 of our Agile journey, we continue to work towards being a truly Agile enterprise.  The cultural change to be an Agile enterprise is constantly a work in progress and the journey never really ends.  Each day, we just try to be a little more agile than we were the day before.


Agile Transformation Success Story at Valpak

Agile Transformation Success Story at Valpak

The latest blog post from Mike Kavis on Valpak’s Agile transformation story.


Agile Transformation: From The Trenches

I am very pleased to introduce guest blogger, Toby Morris, for this latest post.  Toby, known around these parts as “The Amazing Toby”, is a software developer at Valpak.  Toby has been with Valpak for many years and has had the opportunity to experience our Agile transformation from the trenches, as the title of this post suggests.  Toby gives a (sometimes brutally) honest and extremely insightful perspective on Agile.  Enjoy!

Over the past year, this blog has chronicled the Agile transformation of a company from the viewpoint of a self-professed “Agile enthusiast”. So, you have to take those posts with a grain of salt. Of course she’s going to have a relatively rosy version of things, seeing the big picture, seeing how upper management reacts to the change, seeing how the new practices is affecting the quality and quantity of product being produced. But one of Agile’s tenants is people over processes. So to truly judge the success and impact of Agile on a company, you have to get in the trenches and see how those changes are impacting the grunts. From the viewpoint of a grunt, I’m pleased with the change.

To show how things have changed, I have to tell you how they were. Just prior to our Agile transformation, we had several problems as a department. Morale was pretty low, and people were fairly unhappy with their jobs. Our department held a series of meetings to try and find the root of this dissatisfaction. After a few talks, some common themes emerged.

Most technical workers in the department had a director, a manager, and sometimes a lead. Most worked on multiple project teams, and each project team had at least one Project Manager. Each Project Manager considered their projects and tasks to be the highest priority for their teams. People were being pulled apart by competing PMs.

Another common issue was unrealistic expectations for project performance. We frequently worked on projects that were breaking new ground, but were required to make estimates that were little more than wild guesses, and we were held to them. If we “guessed” it would take six months to learn and implement a new technology, but it actually took eight or nine months, we would fail, leaving a shattered trail of disappointed business people and angry project managers.

Along with the missed deadlines, the business was becoming concerned about our ability to deliver quality products in reasonable amounts of time. We constantly ran over, and with every looming deadline, overtime pushes, sometimes all night and all weekend long, were the norm.

When the big leap was announced, there was a lot of skepticism. We were in a very sore spot, and now someone wanted to move our cheese. They actually wanted to replace our cheese with some type of healthy, new age vegetable, and we were scared. We were confused. There was a great deal of apprehension. How could we do everything we’ve been doing in a tried and true Waterfall world in short, little two-week sprints? And even if we could do it, why bother? Would it really make a difference?

Yes, it did.

We went from having multiple overseers to overseeing ourselves. We had one person determining what we’d work on, and we would decide how we did it. We broke big, multi-month projects into small, two-week stories. Some teams even broke them down smaller, opting to work in simulated one-week sprints.

It wasn’t easy to change. We all had to move, physically, to be closer to our teams. And we lost our walls. We moved into more collaborative cube setups. This provided a much more significant benefit than imagined. Sure, we could communicate readily now. No more emails or phone calls. No more standing up and walking across the room to ask a simple question. We could now turn, get the person’s attention and get our answer in seconds. Sure we could more easily collaborate. Having the developer sitting next to the QA, or the front tier, middle tier and back-end guy sitting next to each other, we could make changes and fixes in minutes rather than hours. But the real benefit is camaraderie. These people that we self-organize with become more like friends than just co-workers. A true sense of team starts up, and before you know it, you’re working together more efficiently.

We also had to learn new words and principles and practices. We learned how to effectively scrum each morning. We learned how to write user stories, and break them into actionable tasks. We even got yellow penalty flags to throw at others when they slipped up and let some waterfall back in.

We had a lot of changes.

But we got more benefit from those changes than imagined. Working in small, self-organizing teams, with a single product owner determining what we were working on for the next two weeks made all the difference. No longer did we have ambiguously ranked priorities. We knew exactly what needed to be done first, second and third. No more were we getting constant interruptions and additional tasks from various project managers. What we have to work on at the start of the sprint is what we’re working on for the whole sprint, and heaven help the person that tries to add a user story mid-sprint.

By our second sprint the business had already noticed and welcomed the new process. Instead of waiting months to see anything tangible, and to find out a project would be delayed even further for obscure, incomprehensible technical reasons, they were now seeing incremental upgrades to existing apps and new features being added to new apps on a bi-weekly basis. And even better, their feedback was incorporated into the rapidly evolving applications they depend on. They were helping to shape the tools they use.

Having a business person intimately connected to each technical team also opened the top secret technical world up and exposed our black magic. We gave our product owner an understanding of the whys and hows of software development. There were no longer the “we’re unable to do that for technical reasons”. Now, we would tell him that the protocol we’re using doesn’t support that level of encryption, and that we’d need to re-engineer the system to use a different API to achieve his needs. And that it would take another sprint to discover what that would require. And he would understand what we’re saying, why it’s causing a delay, how long the delay will be and ways to work around it. The smaller tasks and user stories mean smaller and easily recoverable failures.

Collaborative and adaptive. That’s how we work now. Morale from a technical worker standpoint has significantly improved. Our products are visibly more stable, bug-free, and valuable. Our business teams are now part of the team, and believe in our ability to make their jobs easier. We are no longer adversaries. We are agile, not hostile.


Yes, we work with an Agile coach

The more popular this blog gets, the more calls I get from Agile consulting companies wanting to “help”.  That’s sweet and all, but we already work with an Agile coach here in Tampa Bay.  Since 2011, we’ve partnered with AgileThought.  They have “Agile” in their name so they must know what they’re doing!  But seriously, we’ve got their CTO, Ryan Dorrell, as our Agile coach.  He has the best bedside manner we could have hoped for and is always the voice of reason on all things Agile.  And, Ryan will forever be my Agile phone-a-friend.  Our arrangement consisted of customized training, coaching, and strategic guidance, among other things.  In fact, our relationship has been so successful that we are submitting for a local collaboration award as we speak.  Wish us luck!

Now that that is cleared up, I do want to take a moment to express the importance of having an external / independent Agile Coach to assist and guide your transformation.  Attempting to DIY (Do It Yourself) Agile can sometimes backfire.  In my experience, money spent on an Agile coach is definitely money well spent!  You need to spend the money to bring on an Agile coach for at least 6-months to train the teams and support the process. As human beings, we can laugh about the notion that we are more willing to take advice from a stranger than from a family member.  This is true in the business world as well (and that’s why consulting is big business).  Companies often tend to appreciate the advice of an independent expert more than a trusted member of the company’s own staff.  Also, an Agile coach can really have your back when it comes to resistance at any level.

Now, where I could use some help is if you are an Agile speaker and plan to be in the Tampa Bay area.  The Tampa Bay Agile Meetup group is always in need of speakers.  It might just be your way of reaching other companies that do indeed help with their Agile transformation.  Leave a comment if that opportunity interests you.


Valpak’s Agile Transformation Video

I know I’ve been promising this for a while, but now I’m delivering on that promise.  I have for you the world premiere of Valpak’s Agile Transformation video.