Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group in Melbourne. It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.
As part of the session, I shared some of the challenges of scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS).
Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises. They are People, Process, Tools/Technology and Org Structure/Culture.
I have summarized the challenges into this diagram
Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.
The popular Scaling Frameworks are as follows: Spotify, XScale, SAFe, DAD (Disciplined Agile Delivery).
In addition to the above, Large Scale Scrum(LeSS) by Craig Larman is popular as well. I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects. LeSS huge can be depicted as shown in the diagram below:
LeSS is based on some of the proven principles around Queuing Theory, Systems Thinking and Empirical Process Control as shown below.
If you want to learn more about applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.
The Agile Manifesto values “Individuals and Interactions” over “Process and Tools.” I suspect it was no accident that this was listed first. Lack of communication, miscommunication, or the mistaken presumption that communication has occurred, are the root cause of many problems. Yet, we still focus much discussion on the process and tools.
- When and how do you conduct a certain Scrum ceremony?
- Are you practicing pure Scrum?
- Which agile tools do you use and why?
- How do you use the tool?
- What agile metrics are you using and how?
- What best practices exist?
- And lots more concerns and questions about how to “do” process…
However, most all change transformations to “be” agile struggle with organizational culture and many organizations and teams continue to fail to reach their full potential because of issues related to “individuals and interactions.”
Teams are the heartbeat of agile development. It’s the people that produce business success. Even when the organizational culture embraces agile values, the teams must also address their individuals and healthy interactions among them to maximize value. This takes time and effort to mature. I find we mistakenly assume that since people know each other already and even “behave” nicely, they think they can skip over the team-building activities.
Simply gathering individuals together and assigning them the label of “team” does not make a team. Each team is comprised of unique personalities and thus there is no cookie-cutter best answer for every team. Each team must find its own way and navigate the uniqueness of each individual to determine the best way to handle interactions that work for their team dynamic. There should be “pacts” that everyone on the team agrees to. If there are dysfunctions (egos, prima donnas, passive aggressive behavior, apathy, poor listening skills, a presumed hierarchy, and so on), then the challenge is an order of magnitude that’s much more difficult. Each team is a unique, dynamic system, subject to changing moods and their environment.
Sadly, some agile teams never evolve beyond a collection of individuals who meet together at the prescribed Scrum ceremonies and then return to work independently with a focus on their individual tasks only. Maybe the ability to track their work has improved, but they have failed to recognize and harness the true potential that comes from working as a high-performing team. Perhaps you have seen teams who are full of energy and so you recognize the power of teams? So, why do some teams never get there? There are multiple factors that influence agile and Scrum teams.
Let’s assume that the organization’s leadership values the power of teams and has a supportive culture and vision in play. So what can be done within the team to ensure that it sets a solid foundation for growth and success?
During the team forming stage, it is important for the team members to openly discuss behaviors and expectations. There is great value in recording those discussions as a reminder to the members when they do encounter problems. But, they need to dive deeply into what each member truly believes and feels. Because what you believe and how you feel directly determines how you will behave. These team discussions must go beyond the process-mechanics agreements such as what time to meet. They need to communicate something more of an “agile team creed” or list of pacts they make with one another. Team members must be comfortable sharing their fears and concerns.
Having an agile team creed is a great starting point for deep team discussions to root out true beliefs. It captures cultural expectations and behaviors for the team which I believe lay the foundation for a great agile team. Here is my list of 15 useful pacts agile teams can make. I call it the Agile Team Creed.
Has your team had these deep conservations about what they believe? Would they agree with these items as part of their Agile Team Creed? If not, why? Perhaps, it reveals a cultural issue that needs attention.
LeanKit’s new Connections functionality has been released to all Portfolio Edition accounts. Find out how this enables you to track and manage work distributed across multiple teams and boards — without losing sight of the details. For some time now, LeanKit has provided the ability to create drill-through relationships. This functionality enabled you to establish parent-child associations between a […]
The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixed methods like Scrum or Kanban. If you are using fixed methods, the proscription is to treat the process in a fractal fashion, repeating it everywhere. Practically speaking, by having only one process these methods ignore the context.
So what are the four contexts of Swarming? Here they are in no particular order:
- Shifting Gears
Emergencies represent the simplest context for swarming. When a crisis occurs, it’ all hands on deck. Everyone joins the conversation and brings whatever specific expertise they have to the party. The group self-organizes to enable those present to contribute to solving the problem. You see this a lot in production operations environments when a “P1″ defect occurs or, heaven forbid, the production system goes down. When this happens, everyone swarms on the problem. Some are gathering information, some are listening and integrating the information, and some are taking action to try and remedy the situation. All of this is happening dynamically in the moment without central organization. All of these activities are critical to the success of the swarm. During a crisis, nobody is going to stop what they are doing for a standup meeting, and they sure as hell aren’t interested in seeing your Kanban board.
Shifting gears refers to when the system is in transition. The corporate ecosystems that we are all a part of are changing faster with every passing day. New products are coming to market and disrupting the old ones. It’s not enough to simply work within the existing system. You can’t keep up that way. These days corporations have to match their structure to the complexity of the environment. That’s hard, and that’s where swarming comes in. Like when honey bees form a swarm, the corporation reaches a critical mass where a new structure is necessary. Up until this point, the hive has been a stable and reliable structure, but with the presence of a new queen everything changes. A cascade of events takes place where the hive moves on. This can also happen with companies. When they reach a certain size, they can spin off subsidiaries, divisions, and even teams. We see this when teams reach critical mass and split into two teams (meiosis). On swarming teams, we use simple rules to enable groups to decide on their own when division should take place (Team size of 7 plus or minus 2). We use the swarming values and principles to help guide who works on each team – always leaning toward letting individuals decide based on where their own passions take them.
In swarming, Innovation is treated as foraging. We are foraging for new information and new ideas. In this context we are actively using our social networks to recruit new people and new ideas to our cause. This can be initiated as part of a special state (shifting gears) or it can be part of the ongoing activities of the team. When ants are foraging, they tend to follow the strongest pheromone trails to a food source. However this rule is not universal. There are ants who wander off the pheromone trail from time to time. These solitary explorers are the ones who have the unique opportunity to wander off the beaten path and potentially find rich new sources of food. So too, we want people on our team not to follow the team too closely. It’s best if they can wander off and explore side avenues and blind alleys. This isn’t something that is dictated, it’s a natural part of teams with rich diversity. People make these decisions on their own and either bring them back to the original team or they form a new team.
Building takes place when we are trying to strengthen our networks. As a team is growing it uses it’s social networks to strengthen bonds both within and without the team. This can be as simple as increasing the number of social “touches” on a team. Social touches are things like: greeting each other, going out to lunch together, supporting each other’s work. There are some people who are stronger at this than others. Some people tend to form many lightweight social contacts (which is very useful). On the other hand, there are those who only have a few deep, strong relationships. A good swarming team is composed of a healthy balance of both types of people.
In summary, swarming is used differently based on the context you are in. Understand the context, and you are prepared to take advantage of the power of swarming.
Filed under: Agile, Swarming, Teams Tagged: animals, building, context, emergencies, innovation, Kanban, methods, Scrum, shifting gears, Swarming, Teams
I’ve been playing around with PostgreSQL recently and in particular the Northwind dataset typically used as an introductory data set for relational databases.
Having imported the data I wanted to take a quick look at the employees table:
postgres=# SELECT * FROM employees LIMIT 1; EmployeeID | LastName | FirstName | Title | TitleOfCourtesy | BirthDate | HireDate | Address | City | Region | PostalCode | Country | HomePhone | Extension | Photo | Notes | ReportsTo | PhotoPath ------------+----------+-----------+----------------------+-----------------+------------+------------+-----------------------------+---------+--------+------------+---------+----------------+-----------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+-------------------------------------- 1 | Davolio | Nancy | Sales Representative | Ms. | 1948-12-08 | 1992-05-01 | 507 - 20th Ave. E.\nApt. 2A | Seattle | WA | 98122 | USA | (206) 555-9857 | 5467 | \x | Education includes a BA IN psychology FROM Colorado State University IN 1970. She also completed "The Art of the Cold Call." Nancy IS a member OF Toastmasters International. | 2 | http://accweb/emmployees/davolio.bmp (1 ROW)
That works fine but what if I only want to return the ‘EmployeeID’ field?
postgres=# SELECT EmployeeID FROM employees LIMIT 1; ERROR: COLUMN "employeeid" does NOT exist LINE 1: SELECT EmployeeID FROM employees LIMIT 1;
I hadn’t realised (or had forgotten) that field names get lower cased so we need to quote the name if it’s been stored in mixed case:
postgres=# SELECT "EmployeeID" FROM employees LIMIT 1; EmployeeID ------------ 1 (1 ROW)
From my reading the suggestion seems to be to have your field names lower cased to avoid this problem but since it’s just a dummy data set I guess I’ll just put up with the quoting overhead for now.
I’ve been playing around with R data frames a bit more and one thing I wanted to do was derive a new column based on the text contained in the existing column.
I started with something like this:
> x = data.frame(name = c("Java Hackathon", "Intro to Graphs", "Hands on Cypher")) > x name 1 Java Hackathon 2 Intro to Graphs 3 Hands on Cypher
And I wanted to derive a new column based on whether or not the session was a practical one. The grepl function seemed to be the best tool for the job:
> grepl("Hackathon|Hands on|Hands On", x$name)  TRUE FALSE TRUE
We can then add a column to our data frame with that output:
x$practical = grepl("Hackathon|Hands on|Hands On", x$name)
And we end up with the following:
> x name practical 1 Java Hackathon TRUE 2 Intro to Graphs FALSE 3 Hands on Cypher TRUE
Not too tricky but it took me a bit too long to figure it out so I thought I’d save future Mark some time!
I’ve heard people say, “We started using Jira and GreenHopper, so we’re Agile now”. Similar things are said of Rally, VersionOne, LeanKit, TargetProcess, etc. In making those declarations, it’s clear that they don’t understand Agile at all.
Underlying these is a mindset with a focus on self-discipline, self-organization, and adaption to change.
The Practices of Scrum (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), the Roles (ScrumMaster, Product Owner, and Development Team), and the Artifacts (Product Backlog, Sprint Backlog, and Product Increment) only help the team support the principles and achieve the goal of delivering working software.
Electronic tools (Task walls, Development Environments, …) or physical tools (Task walls, …) are only useful in so far as they provide support for those principles and practices.
If your Agile adoption starts with a tool and a scattering of practices, then the whole point has been missed and the core – the essence – of Agile needs to be carefully reviewed until that is obvious.
I’m a September baby and this year, I treated my friends at work to the most scrumptious cake I’ve ever seen. What better way to remind us of transformative journeys along the Yellow Brick Road than with the Rainbow Cake by Hummingbird Cafe.
Folks ummed and ahhed at the sight of the multi-coloured layers of this beautiful cake only to be further and pleasantly surprised by the bubble gum flavoured icing as they savoured their slice.
“If I still wrote software, this would be the kind of software I’d create,” I mused, drunken on sugary goodness.
“Don’t you think that would smack of over-engineering?” remarked a fellow cake-connoisseur.
Of course, what I really meant to say is that I marvel at the thought of creating something so thoughtful and thought-provoking as the Rainbow cake. A work of exquisite (and, optionally, edible) beauty that would brighten the world and remind us of what passion, creativity and craftsmanship can produce.
All this serves as a timely reminder that we need to live our dreams to make them come true.
Here’s to enjoying the rainbows on your journey of a lifetime. Happy Birthday one and all!
Visibility is a wonderful thing. Making your team’s work transparent lets every stakeholder judge current status and progress at a glance. This transparency also reveals impediments – is one story blocked by another? Is something holding up progress? Are some activities turning into bottlenecks? Seeing a snapshot of a team’s current status and progress is also a conversation starter: “I have a question about this story – oh, I see that Joe, Debbie and Mary are all working on it, I will ask them”.
Tracker has provided visibility into individual software projects for years. But your organization probably isn’t working on one simple project. Maybe you have more than one code base for your product, for example, a back-end server, a front-end web app, a mobile app. You might have multiple versions of some of those, too. Oh, and there’s a lot of supporting work to track: DevOps activities, testing across multiple code bases, UX design. It doesn’t make sense to shoehorn everything into one project. But managing multiple projects can get pretty complicated. The beta version of Tracker offers an approach that works well for many teams that have multiple products or projects to manage: workspaces. Tracker users have the option to view and manage several Tracker projects side-by-side in their multi-project workspace. Let’s look at the multiple joys that multi-project workspaces have to offer. Improved Visibility When you create a multi-project workspace, you can load relevant panels from all your projects into one Tracker session, and see progress in all of them at a glance. If you’re working on stories in more than one project, you can see all your current stories in all projects in the My Work panel. See the screenshot above for an example My Work across multiple projects.
If your team currently uses a single project for all stories, and manages different tracks with epics, consider giving each track its own project. The multi-project view gives a simpler high-level view, with color coding to distinguish project panels. Click the icon at the top left of the sidebar, above the Add Story button, to manage your workspace. As well as adding and removing the Projects you would like in your workspace there, via the “add/remove projects” dialog, you can change project colors. You can also customize your colors in single project view by clicking on the color icon at the top left. Easy, Flexible Organizing Let’s say your team creates projects for your front-end code, your back-end server, a mobile app, DevOps chores, and system testing charters. You’re a tester who gets involved in all of these (yes, multi-tasking is bad, but cross-functional knowledge and involvement is good!) You add all these projects to your Tracker workspace so you can see the big picture. Tracker remembers what panels you had open the last time you used your workspace, and in what order, so you don’t need to tweak your panel layout each session. You start testing delivered stories in the front-end project, because that release is coming up soon. As you are testing, you discover a new bug in the back-end code. Without having to switch to a different Tracker view, you add a bug story to your back-end project Icebox. While looking at the back-end project’s Icebox, you realize that a bug story you entered earlier is really a problem on the front-end. You simply drag that story over to the front-end Icebox panel where it belongs. Before returning to testing your front-end stories, you see a new in-app notification. Clicking on the story in the notification, Tracker opens a story in the mobile app project. A new feature you’re keen to test has just been delivered, so you make a mental note to check that out later. A little while later, you’ve caught up with testing the front-end stories. Your next priority would be to test delivered back-end stories, but you can see nothing has been delivered yet. There is also some exploratory testing to do on the front-end, but you can see that a developer pair has been cranking through the test charters in your system testing project, so you go test that fun new mobile app feature. Managing Dependencies There are many ways a story can get blocked. It may be waiting for a design element or a change to an API. It might be blocked by a story in the same project, or one in another project. We like to make this visible by putting a “blocked” label on the story, along with a link to the story that’s blocking it. For example, if it’s waiting for a design story, the label may be “needs design”. If a delivered story can’t be accepted yet due to a dependency on another story, it gets an “accept blocked” label. The blocking story also gets a label and a link to the story it’s blocking. This information stays front and center for everyone on the team. This kind of visibility is even more crucial when multiple teams work on the same or related products.
Since Tracker allows you to search across all projects in your workspace, you can bring up all stories with a particular label. They’ll display in a panel ordered by project. Promoting Conversations Along with multi-project workspace, Tracker beta provides other features to enhance communication. Each Tracker user can customize their own settings for in-app notifications. The bell icon at the top of the page indicates the number of unread notifications. When you open a notification, you can click to open the story, regardless of what projects you currently have open. Project members can quickly get attention from others with @mentions, which get special highlighting. Then, if necessary, they can have a face-to-face conversation about the story or epic. Finding Stuff Faster When you’re involved in multiple projects, it can get hard to remember which stories are where. In Tracker’s multi-project workspace, the searches you request will retrieve matches in any of the projects in your workspace. It saves time, plus you’ll see stories in other projects that may be related.
I often click on a label for a quick overview of all the stories in my workspace with that label. We’ll be enhancing the ability to organize your work with saved searches in workspaces later on.
If you haven’t experienced the joys of the multi-project workspace, click the button at the top of your project page to switch to Beta. When you get there, check out the Beta Overview panel (accessed via the Help & Updates menu at the top right of your Tracker window) to see how to configure your workspace. Enjoy improved visibility into project progress and impediments, and better communication with your teammates. In the coming weeks, we will be adding more capabilities including the ability to create multiple workspaces, each with a different set of projects. Are you already using a multi-project workspace? We’d love to hear how you’re making the most of this new feature. Please comment and share your experiences.
Will you have a job in the future?
What will that job look like and how will the nature of work change?
Will automation take over your job in the near future?
These are the kinds of questions that Ruth Fisher, author of Winning the Hardware-Software Game, has tackled in a series of posts.
I wrote a summary post to distill her big ideas and insights about the future of jobs in my post:
Fisher has done an outstanding job of framing out the landscape and walking the various arguments and perspectives on how automation will change the nature of work and shape the future of jobs.
One of the first things you might be wondering is, what jobs will automation take away?
Fisher addresses that.
Another question is, what new types jobs will be created?
While that’s an exercise for the reader, Fisher provides clues based on what industry luminaries have seen in terms of how jobs are changing.
The key is to know what automation can and can’t do, and to look at the pattern of work in terms of what’s better suited for humans, and what’s better suited for machines.
As one of my mentors puts it, “If the work can be automated, it’s not human.”
He’s a fan of people doing creative, non-routine work, where they can thrive and shine.
As I take on work, or push back on work, I look through a pretty simple lens:
- Is the work repetitive in nature? (in which case, something that should be automated)
- Is the work a high-value activity? (if not, why am I doing non high-value activities?)
- Does the work create greater capability? (for me, the team, the organization, etc.)
- Does the work play to my strengths? (if not, who is a better resource or provider. You grow faster in your strengths, and in today’s world, if people aren’t giving their best where they have their best to give, it leads to a low-impact team that eventually gets out-executed, or put out to Pasteur.)
- Does the work lead to world-class impact? (When everything gets exposed beyond the firewall, and when it’s a globally connected ecosystem, it’s really important to not only bring your A-game, but to play in a way where you can provide the best service in the world for your specific niche. If you can’t be the best in your niche in a sustainable way, then you’re in the wrong niche.)
I find that by using this simple lens, I tend to take on high-value work that creates high-impact, that cannot be easily automated. At the same time, while I perform the work, I look for way to turn things into repetitive activities that can be outsources or automated so that I can keep moving up the stack, and producing higher-value work … that’s more human.
In an earlier post, we announced the development of a new solution framework: SAFe for Lean Systems Engineering (SAFe LSE for short). Work continues at a pretty good pace, and the team (mostly Dean, Harry, Inbar, Alex, Regina so far) have been pretty busy putting up the new site, developing content, and of course, working on the Big Picture for SAFe LSE.
As we often discuss in SPC class, the BP serves as the domain model for the framework, as it it identifies the people that do the work, their major activities, and the work products that capture decisions and help guide the flow of work.
To that end, attached is “v 0.21″ of the SAFe LSE BP, being the 21st internal revision of this diagram. It’s far from done (SAFe reached over 100 revs before I stopped counting) but we think it tells an adequate story to start with. Of course, it isn’t fully self-explanatory, for that we need content and the website, but we think those building big complex systems can get an idea where we are headed with this version.
As for the near-future roadmap, we will go live with a preview version sometime in November. That one will be fully open for comments, so all can participate in adding value and criticism, as the case may be.
We do look forward to your input, and be assured that we have now fully committed to this initiative, so there will be a first GA release of SAFe for Lean systems Engineering sometime in 2015.
PS: If you check the earlier post, you’ll see that Manifesto, which will also be elaborated with hyperlinked SAFe LSE principles, has also been updated, based on a lot of feedback we have garnered so far
PPS: We are also building a new 3-day training course:
Leading SAFe LSE: Leading Lean Systems Development with SAFe for Lean Systems Engineering.
The first version of this course will be delivered the first week in February, in the Boulder training center. We should have that course available for registration later this week.
I posted my most recent Pragmatic Manager newsletter, Scale Agile With Small-World Networks on my site.
This is a way you can scale agile out, not up. No hierarchies needed.
Small-world networks take advantage of the fact that people want to help other people in the organization. Unless you have created MBOs (Management By Objectives) that make people not want to help others, people want to see the entire product succeed. That means they want to help others. Small-world networks also take advantage of the best network in your organization—the rumor mill.
If you enjoy reading this newsletter, please do subscribe. I let my readers know about specials that I run for my books and when new books come out first.
The second of our new role-based training classes focuses on replenishing your kanban system. We look at the risk management typically undertaken by product managers. Kanban offers very elegant solutions to the problems of large backlog management and prioritization. For anyone who has to decide what to work on now, what to leave until later and what to discard altogether, this is the class for you. If you want to understand how to select work for your kanban system, how to schedule it, how to sequence it and how to define classes of service to control the flow of work through the system, then this is the class for you. This class includes coverage of so called "upstream Kanban" and Real Option Theory. You'll learn to stop using the term "backlog" except for large projects with defined scope, and how to understand a "pool of ideas" as a set of options to be developed or discarded. You'll learn how to filter options based on risk assessment, how to hedge risk with capacity allocation, and how to schedule and select work, pulling it into the kanban system at the optimal time.
This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Product Management for Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.
We train people all the time. The topics vary from Scrum Training to learning how to prioritise. Over the last 3 years we learned that we can’t just stand in front of a bunch of people and lecture to them. Well we can, but we’re doing them a disservice if we do. We have done a lot of reading into how people learn and what techniques to use to maximise learning during a course. Most recently we have been thinking about the online education platform. It’s a booming business – but can you learn as well online as you can in person? Let me talk you though our teaching education…
Our research introduced us to Training From the Back Of The Room (TFTBOTR) by Sharon Bowman. The basics of this was that to increase retention you should try and teach something in various ways. Repetition is key, as well as getting the students to do things and talk, rather than just the trainers talking. We fully embraced this and converted all our training use a 4C template (you can download it here).
Next we started thinking about duration of the course and training. In our experience, spending 2 days on a course does not convert to 2 days of knowledge. Usually people are so tired by day 2 that we absorb very little. 1 day of training is ok, but 2-4 hours is even better. Based on this, we then converted a few of our longer training courses into smaller 2-4 hour interactive workshops.
So how do we translate highly interactive Training From The Back Of The Room to an online medium? Most online courses we have seen are simply videos. Some have talking heads, some just have voice, and some have voice with powerpoint. Exactly the opposite of our TFTBOTR learnings. We decided to look at a blended approach. What would happen if we structured each online section of the course like a 4C plan?
Our first attempt looks something like this:
- A short 5 min exercise to involve you with the topic. This involves writing and thinking. This is a Connection (C1) activity.
- A short 3-8 min video with us teaching the topic. This involves listening. This is a Content (C2) activity.
- Additional reading (mostly blog posts) and video (like a TED talk) for you to watch. This involves reading. This is also Content (C2) activity.
- A few powerful questions for you to answer in your journal. This involves applying the knowledge to your work environment and writing it down. This is a Concrete Practice (C3) activity.
- A technique or experiential game to use with your teams. This involves doing and talking. This is a Concrete Practice (C3) activity.
- A challenge. This varies between talking, doing, writing, reflecting. This is a Conclusion (C4) activity.
We feel that if you follow each of the steps you might get very close to an in-person training experience. Our first course on Leadership has been published. The section on Listening is available for free. Take a look to see how you think this compares to in person training.
If you would like to take the whole course – join our newsletter and receive a 50% discount once we have launched in October!
Here are some TED talks on online education and why you should care
Daphne Koller: What we’re learning from online education
Salman Khan: Lets use video to reinvent education