Expectations are everything. If you set a goal, communicate it and then meet it, your team is thrilled and so are your stakeholders.
In the previous post, we outlined the Agile Resource Allocation Dilemma and recognized that this is a pervasive issue and a tough one to solve.
Happy to report that I took the Certified Scrum Profession (CSP) exam this morning and passed with flying colors! My biggest reason for working towards the exam was using it as a forcing function to do a whole lot of reading about a variety of agile subjects. Over the past 8-9 months, I read the following titles and added to my knowledge base using mind mapping software (I love iThoughtsHD on the iPad):
Congratulations! You have now convinced your management team to adopt agile. Everyone (or at least most) in your leadership team have extended their support toward this initiative. Everyone believes that this transformation will be excellent for your organization as 1) you are adopting agile 2) claim that your organization is challenging the status quo and 3) you will be able to do product delivery faster.
I have a new article published today with Scrum Alliance on why release orientation (vs. project orientation) is so important to being agile and critical to scaled agile.
This article is about the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skill teams.
Pulling all the ideas together from this article series, I want to leave you with a couple of key thoughts when you are trying to design your agile organization:
In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.
In previous articles, I outlined the guiding principles for organizing agile teams (start here if you haven't started the article series yet) and described the Ideal Team Structure (ITS). This is the first in a series of articles to describe various organizational design patterns to start the journey to the ITS given the real possibility that your large organization cannot switch to the ITS immediately upon starting the transition to agile software delivery.
I spent time outlining the guiding principles for organizing agile teams in my last article. With the challenge of delivering business intent where changes to 10’s of platforms / components are needed and we only have developers and testers who specialize in singular platforms / components - how do you organize? There have been many books, whitepapers, and blogs (see here, here, here, and here). talking about the tradeoffs of feature teams (which can also be referred to as business vertical teams or product-aligned teams) and component teams. A feature team spends their days delivering user stories that are highly reflective of needed business intent whereas component teams spend their time delivering user stories that are generated by the feature teams because they need components outside of their scope of knowledge or responsibility modified to deliver the overall solution.
Much of the writing on feature and component teams puts feature teams in the “good” camp and component teams in the “bad” (and sometimes “evil”) camp. With the challenges outlined above, to some degree, component teams might be a necessary evil. The key is that your initial organizational design has feature teams as well and that you are creating an obvious maturity path towards possibly eliminating the component teams by pushing that component skill and knowledge towards the feature teams through knowledge sharing and architectural simplification. Ultimately, the goal is to create feature teams of generalizing specialists, living and collaborating right with the BIG’s (Business Intent Generators), and able to create and modify 100% the system components needed to delivery that business intent – the Ideal Team Structure (ITS).