Archive for the ‘On Being Agile’ Category
If you’ve been following me, then you probably know that I consider Jim Highsmith my mentor. Jim is one of the 17 signers of the Agile Manifesto, a prolific author and blogger, and a truly original thinker. I first met Jim during my last (and horrifying) waterfall project. Jim gently encouraged me to think about how agile might apply to data warehousing. He also taught me a lot about freelance consulting and book writing.
Many of you know who Jim Highsmith is. But for those of you who don’t, Jim has more than 30 years of experience in IT and is the recipient of the 2005 Stevens Award for outstanding contributions to systems development. Jim is also the author of Adaptive Software Development (2000 Jolt Award winner), Agile Project Management: Creating Innovative Products, Agile Software Development Ecosystems and the just-released Adaptive Leadership: Accelerating Enterprise Agility.
In Adaptive Leadership, Highsmith has compiled, updated, and extended his best writings about agile and lean methods for a management audience. Key themes include:
- Drawing on what’s been learned in application development, this guide shows how to use adaptive leadership techniques to transform the way you deliver complete solutions, whatever form they take.
- How enterprise agility can enable the ambitious organizational missions that matter most.
- How leaders can deliver a continuous stream of value.
- How to think disruptively about opportunities and how to respond quickly by creating more adaptive, innovative organizations.
- Integrating economics, products, and social responsibility.
- Understanding the financial implications of technical debt.
“We are at a tipping point. Technology—cloud, big data, mobility, social media—tops CEOs’ list of concerns per a recent IBM study. Companies that emerge successfully from this havoc will need to build agility into the very fabric of their organizations and develop the technological savvy to enable that agility. Adaptive Leadership provides a framework for such a transformation,” Highsmith said.
Read more in a recent Q&A with Jim on the ThoughtWorks Insights page where he talks about the evolution of agile and the role of senior management in an enterprise-wide Agile transformation.
Check out ThoughtWorks’ resources on Agile Project Management.
By Lynn Winterboer and Ken Collier (first published in TDWI BI This Week on July 30, 2013)
Agile leaders focus more on the continuous delivery of high-priority value to business stakeholders and less on making sure each worker is always busy. We explain how your BI program will benefit by limiting developer multi-tasking.
Ben and Susan are each a DW/BI director at their respective companies; each leads a department of roughly the same size. Both have the staffing necessary to organize three dedicated, cross-functional teams. Ben’s department is organized into dedicated teams while Susan has functional skills “pools” from which project teams are staffed. Both directors are planning for the coming year and have a similar set of 12 projects to schedule.
Through collaboration with business stakeholders, product owners, project managers, and the program management office (PMO), Ben has a prioritized backlog of funded project requests to schedule into the calendar. With help from technical leaders, he has completed some high-level project sizing and assigned durations of two, three, or four months per project. Projects longer than four months are divided into multiple phases, each designed to fit into one of these smaller time periods. This ensures that long-running projects do not block other projects by dominating the department’s capacity.
Ben assigns a dedicated team to each of the first three projects in the backlog. He then estimates when each team might be free to start its next project, continuing in this manner until he has a reasonable program plan for the coming year:
Check out this TDWI BI This Week interview of Michael Whitehead by Linda Briggs. Michael is a friend of mine and the very astute CEO of Wherescape, a company that produces tools that enable agile data warehousing. Michael’s comments reflect much of what I mean when I talk about “being agile” rather than “doing agile”. Here is the opening teaser…
“Current data warehouse projects simply take too long to produce value, says CEO Michael Whitehead. All too often projects are built on the assumption that they won’t need to change. Instead, Whitehead advocates delivering value quickly, thus winning the time and budget to continue to improve design.
In this interview, Whitehead shares his thoughts on current data warehouse design, agile development, and the best route to revamping a data warehouse. WhereScape, a data warehousing company, offers WhereScape 3D, a data warehouse planning tool, and WhereScape RED, an integrated development environment (IDE) for building, deploying, managing, and renovating data warehouses and data marts.”
In September, 2012 I had the honor of presenting the keynote address at The Data Warehousing Institute (TDWI) World Conference in Boston. Here is the abstract and video recording of that presentation. I hope you enjoy it.
The carpenter is a skilled craftsman who is adept at reading architectural plans and building what is prescribed. A good carpenter has a well-developed set of skills, high-quality tools, and the experience to build high-quality structures that will last.
The cabinet maker’s work is designed to be seen and must be visually appealing. The joints must appear seamless, and the finish flawless. A good cabinet maker works with the customer to design a functionally effective configuration and select styles, color, and appearance. Unlike the carpenter’s coarse tools, the cabinet maker’s tools are precise and delicate.
The furniture maker’s work must serve a specific purpose, but its actual design and appearance can vary widely. A chair might have arms or not, have a high or low back, be symmetrical or asymmetrical. An innovative furniture maker’s vision is not tightly bound by the appearance of the chair, only by its functionality. The artistic furniture maker is not directed by the customer, but instead measures success by how many customers buy his work.
All three are skilled craftspersons who possess the right skills, tools, and experience. Data warehouse, BI, and analytics practitioners have historically been most like the carpenter, building what the architects prescribe. This talk examines a blend of Lean Startup, Kanban, and agile techniques that offer the opportunity to work more like cabinet makers and furniture makers, infusing creativity, vision, and innovation into our results–-and measuring how well our customers like what we build.
The following post was originally published by the Cutter Consortium as an e-mail advisor for the Data Insight and Social BI practice in December, 2011. Hence, the reference to the holiday season. That publication can be found here.
In honor of the holiday season, this month’s topic is focused on an all-too-familiar problem: the common hangover. No, I’m not speaking of an “adult beverage” hangover, although if I find a cure for that I’ll be sure to share it with you. The type of hangover I’m speaking of is the routine failure of your agile delivery team to complete the user stories it commits to during sprint planning.
I’m surprised at what a common occurrence this is for many agile analytics teams. Here are a few example scenarios:
- The team completes development but testing hangs over into the next sprint.
- The team completes the data integration elements of a story, but the demonstrable corresponding BI features hang over to the next sprint.
- The story is too big to be completed in a single sprint, so the team just allows it to hang over into the next sprint.
There are other examples, but you get the idea. A hangover is not the same as a BI feature that is technically done, but the customer review calls for further modification or refinement (it isn’t “Done! done!”). A hangover is simply a failure to have the completed story ready for customer review at the end of the sprint. Continue reading “Curing the Common Hangover” »
Agile leadership is sometimes portrayed as, “Buy pizza and get out of the way.” Or, “Empowering teams to be more self-organizing and self-managing.” Neither of these descriptions is particularly accurate. Agile leaders have a uniquely challenging role. In fact, in many ways command and control, “my way or the highway” leadership is much simpler. The manager gives direction and the minions follow it. However, effective agile leadership results in much higher performance, greater innovation, and exciting new ideas.
One of the many things that agile leaders do is motivate teams. Dan Pink is the author of the recent best seller, Drive: The Surprising Truth About What Motivates Us. You may have seen Dan Pink’s “Motivation” presentation on Ted. This video went viral a couple of months ago. But, even more compelling is this artistic animation of Dan’s earlier talk. Give it a look, it’s well worth 10 minutes of your time.
In June, 2010 The Data Warehousing Institute (TDWI) published my article entitled “Being” Agile vs. “Doing” Agile as part of their “This Week in BI” series. Although I wrote the article for the Agile BI community, the concepts apply to any agile development organization. Please give it a read and let me know what you think.
I occasionally get asked to describe agile project failures and struggles. I haven’t formally studied root causes of failure but have worked with enough struggling agile teams to gain a qualitative sense of these causes. Agile struggles are commonly caused by non-agile behaviors masked behind agile trappings and terminology. Failure to collaborate is a common problem. People tend to revert to the asynchronous communication (e-mail and written documents); and “throw-it-over-the-wall” habits with which they’ve grown familiar. Continue reading “On Community, Customers, and Collaboration” »
In 2006 NBC launched a television series in the U.S.A. called Studio 60, a comedy/drama about the production of a weekly live variety show ala Saturday Night Live. The series gave viewers a behind the scenes look at the intensity with which each new weekly variety show is planned and executed. Unlike typical weekly TV shows, each episode of a live variety show is planned in a “just in time” fashion. The content must be adapted to current events, the decisions of producers must be responded to immediately, and the cast and crew must be highly adaptable to change. No matter what happens during the week, the show must be completely planned and ready to air at a fixed time. And it must be good enough every week to keep viewer ratings very high or risk cancellation. Imagine the pressure!
I’ve been reflecting a bit on my Cutter 2010 prediction – “Although Agile adoptions will proliferate, we will see an increase Agile project failures due to misunderstanding, misapplication, and misguided attempts to follow an ‘agile recipe’.” It feels a little pessimistic to me so I wanted to elaborate further and hopefully give readers some ideas about how to avoid experiencing an agile failure. As an agile consultant I get to work with a lot of different companies in various stages of agile transformation; with varying corporate cultures; and experiencing varying challenges and successes. Through these experiences success patterns and anti-patterns emerge. Continue reading “Adapting is Key” »