Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell. For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting. Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective. I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program. I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach. This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge! I’m looking forward to bridging that gap!Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
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!
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.
Over on the AgilePDX mailing list, there's an interesting conversation on making predictions with Agile. It started off with Michael Kelly asking if Agile can help with predictability. Here's my response:
It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.
Software is inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have.
One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.
Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff in XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*) They can and do provide reliable predictions.
Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions just as well as two-star teams can, but estimating and predicting has a cost, and those predictions often have no real value in the market. They often choose not to incur the waste of making predictions.
So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability the organization wants.
I describe the "how to" of making predictions with Agile in "Use Risk Management to Make Solid Commitments".
*The error-bar numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.
I’ve been working through the exercises from An Introduction to Statistical Learning and one of them required you to create a pair wise correlation matrix of variables in a data frame.
The exercise uses the ‘Carseats’ data set which can be imported like so:
> install.packages("ISLR") > library(ISLR) > head(Carseats) Sales CompPrice Income Advertising Population Price ShelveLoc Age Education Urban US 1 9.50 138 73 11 276 120 Bad 42 17 Yes Yes 2 11.22 111 48 16 260 83 Good 65 10 Yes Yes 3 10.06 113 35 10 269 80 Medium 59 12 Yes Yes 4 7.40 117 100 4 466 97 Medium 55 14 Yes Yes 5 4.15 141 64 3 340 128 Bad 38 13 Yes No 6 10.81 124 113 13 501 72 Bad 78 16 No Yes
filter the categorical variables from a data frame and
If we try to run the ‘cor‘ function on the data frame we’ll get the following error:
> cor(Carseats) Error in cor(Carseats) : 'x' must be numeric
As the error message suggests, we can’t pass non numeric variables to this function so we need to remove the categorical variables from our data frame.
But first we need to work out which columns those are:
> sapply(Carseats, class) Sales CompPrice Income Advertising Population Price ShelveLoc Age Education "numeric" "numeric" "numeric" "numeric" "numeric" "numeric" "factor" "numeric" "numeric" Urban US "factor" "factor"
We can see a few columns of type ‘factor’ and luckily for us there’s a function which will help us identify those more easily:
> sapply(Carseats, is.factor) Sales CompPrice Income Advertising Population Price ShelveLoc Age Education FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE Urban US TRUE TRUE
Now we can remove those columns from our data frame and create the correlation matrix:
> cor(Carseats[sapply(Carseats, function(x) !is.factor(x))]) Sales CompPrice Income Advertising Population Price Age Education Sales 1.00000000 0.06407873 0.151950979 0.269506781 0.050470984 -0.44495073 -0.231815440 -0.051955242 CompPrice 0.06407873 1.00000000 -0.080653423 -0.024198788 -0.094706516 0.58484777 -0.100238817 0.025197050 Income 0.15195098 -0.08065342 1.000000000 0.058994706 -0.007876994 -0.05669820 -0.004670094 -0.056855422 Advertising 0.26950678 -0.02419879 0.058994706 1.000000000 0.265652145 0.04453687 -0.004557497 -0.033594307 Population 0.05047098 -0.09470652 -0.007876994 0.265652145 1.000000000 -0.01214362 -0.042663355 -0.106378231 Price -0.44495073 0.58484777 -0.056698202 0.044536874 -0.012143620 1.00000000 -0.102176839 0.011746599 Age -0.23181544 -0.10023882 -0.004670094 -0.004557497 -0.042663355 -0.10217684 1.000000000 0.006488032 Education -0.05195524 0.02519705 -0.056855422 -0.033594307 -0.106378231 0.01174660 0.006488032 1.000000000
Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.
Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.
“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”
While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.
I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.
When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.
Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.
“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”
So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…
Filed under: Agile, Lean, Process, Scrum, Swarming, XP Tagged: Agile, evolution, Extreme Programming, Kanban, meme, no estimates, Process, software development, XP
When we were kids, we loved to doodle. Most of us did anyway. I doodled all the time, everywhere, and, to the dismay of my mother, on everything. I still love to doodle. In fact, I believe doodling is essential.
The tragedy of the doodle lies in its definition: "A doodle is an unfocused or unconscious drawing while a person's attention is otherwise occupied." That's why most of us have been taught not to doodle. Seems logical, right? Teacher sees you doodling, that is not paying attention in class, thus not learning as much as you should, so he puts a stop to it. Trouble is though, it's wrong. And it's not just a little bit wrong, it's totally and utterly wrong. Exactly how wrong was shown in a case study by Jackie Andrade. She discovered that doodlers have 29% better recall. So, if you don't doodle, you're doing yourself a disservice.
And you're not just doing yourself a disservice, you're also doing your audience a disservice. Neurologists have discovered a phenomenon dubbed "mirror neurons." When you see something, the same neurons fire as if you were doing it. So, if someone shows you a picture, let's say a slide in a presentation, it is as if you're showing that picture to yourself.
Wait, what? That doesn't sound special at all, now does it? That's why presentations using only slides can be so unintentionally relaxing.
Now, if you see someone write or draw something on a flip chart, dry erase board or any other surface in plain sight, it is as if you're writing or drawing it yourself. And that ensures 29% better recall. Better yet, you'll remember what the presenter wants you to rememeber. Especially if he can trigger an emotional response.
Now, why is that? At EUVIZ in Berlin last month, I attended a presentation by Barbara Siegel from Look2Listen that changed my life. Barbara talked about the latest insights from neuroscience that prove that everyone feels first and thinks later. So, if you want your audience to tune in to your talk, show some emotion! Want people to remember specific points of your talk? Trigger and capture emotion by writing and drawing in real-time. Emotion runs deep and draws firm neurological paths in the brain that help you recreate the memory. Memories are recreated, not stored and retrieved.
Another thing that helps you draw firm neurological paths is exercise. If you get your audience to stand up and move, you increase their brain activity by 7%, hightening alertness and motivation. By getting your audience to sit down again after physical exercise, you trigger a rebalancing of neurotransmitters and other neurochemicals, so they can use the newly spawned neurons in their brain to combine into memories of your talk. Now that got me running every other day! Well, jogging is more like it, but hey: I'm hitting my target heart-rate regularly!
How does this help you become a better public speaker? Remember these two key points:
- At the start of your speech, get your audience to stand up and move to ensure 7% more brain activity and prime them for maximum recall.
- Make sure to use visuals and metaphors and create most, if not all, of them in real-time to leverage the mirror neuron effect and increase recall by 29%.
In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.
What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.
Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.
Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.
There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.
A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:
- The Scrum of Scrums or other program or portfolio meetings
- Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
- Attending other forums, other teams status meetings
- Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.
If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.
Filed under: Agile, Process, Scrum, Swarming, Teams Tagged: communication, information radiators, one way broadcast, Swarming
Everyone encourages managers to increase the capitalisation of their areas. If they don't, they won't get funded.
The simplest way to increase capitalisation rate is simply changing numbers in spreadsheets. This is mostly independent of whether or not the work is creating an asset because it's easier to move a number than it is to argue.
I've been told that from a corporate finance perspective, the priority is:
- Appropriate accounting of capital and operating expense
- Effective use of financial investment to achieve strategic goals
Instead, if we want appropriate accounting, we might ask..."How might we improve the accuracy of our accounting?"This might lead to...
- Training sessions, guides, etc. on appropriate capitalisation
- Integration with tooling
- Only assessing capitalisation after delivery of the assets. That is, operating using OPEX and only journalling to CAPEX upon release. I'd call this "as-built accounting".
- Clearer communication of strategic intent
- Collective prioritisation of the portfolio
- Smaller batch sizes to allow for staged investment
- More sophisticated ways of assessing investments (e.g. Cost of Delay)