The first organizational chart (How information design solved a big problem for the Erie Railroad in the telegraph age) was a tree form describing the people and roles of the Erie Railroad with the executives at the bottom.
Erie Railroad Org Chart
By 1917 the org chart had mutated to the now traditional pyramid shape. See Wikipedia article.
A better alternative to the org chart is the Organigraph. "The organigraph shows how companies really work. It uses symbols like stars, funnels, tubes, links and chains—in all, there are six speciﬁc symbols that represent how a company actually works." -- Building Business Value Blog Here's an example:
So do you see how the first Org Chart was both an organizational chart and an organigraph? And why it may have provided great informational value. Here's Enron's organigraph - it reminds me of an attack cell.
What's wrong with your Organizational Structure? by Brian Robertson of Holacracy.org.
The Feb. 19, 2014’s update to Sprintly included a number of key changes.Change to Item Detail Page
We moved up the comment and attachment upload box on the item detail (permalink) page. It is now located right below the item description:
It was formerly at the end of an item’s activity stream, at the bottom of the page. An item’s activity stream will now display from newest to oldest. We heard feedback from our users that it took too much scrolling in order to add new comments and attachments.
This is second in a series of updates for the item detail page. We rolled out a big performance boost to this page on February 5th that enabled quicker and more efficient loading. We will continue making additional changes to make this page so it is more user-friendly. We will be incorporating a lot of the feedback we have received from our user base in future releases.
Performance Update - Dashboard
Included in this release is a significant performance patch to the Dashboard that enables quicker page loading. Also, some users were experiencing issues loading new items or items that recently changed state on the Dashboard. We have removed all local caching for the Dashboard to ensure that all item updates are accurately reflected at all times. We will be deploying this same performance update to other Sprintly pages (e.g. the Organizer) in upcoming releases.
Also included in this release is a fix for a display bug where new items would sometimes appear twice on the Dashboard and for a short period of time or until the page is refreshed. This display bug has been resolved in this latest release.
Other Bug Fixes
Other updates include a fix to the email notifications check boxes in Settings. We also added back in a second warning prompt for deleting a product from the Sprintly system.
Phew! Now we’re back to working on more performance updates and bug fixes! Please don’t hesitate to contact us at email@example.com with any questions or concerns.
I haven’t written much on this blog recently. In those rare spare hours between my full-time job, working on my second book, contributing to my local community, building a studio extension to our tiny house, and raising our wonderful baby (now nine months old) I’ve been building AgileLib.Net as a community platform for sharing agile resources with your fellow travelers.
AgileLib.Net has come far since its inception as ScrumMasters.Com, and now offers a broader range of resources for Agilists of all stripes through a cleaner UI and a much more intuitive user experience. It has a host of useful features including resource categorization, improved (and simplified) search, sorting, tagging, and language filtering to help people find exactly what they need.
Members can create their own personal list of recommendations, follow the lists of others, and see who is following them. The activity stream keeps one up-to-date on new additions to the library, and endorsements to existing resources.
The library now has users from 40+ countries, in all six continents and gets around 300 hits per day. 150 people have created accounts and many more use it anonymously simply to browse and search. I’m hoping to increase membership, and continue to improve the site, responding to user requests.
The publisher, Dymaxicon, is kindly giving away eBook copies of books from their catalog—some good scrum books, but also an eclectic catalog of other books to choose from. Entering a new resource, or endorsing an existing one gives you a 1:20 chance to receive one of these eBooks.
You will notice from the site that there is no negative voting. You only endorse something, or you don’t. This is based on the “Dolphin Training” idea that you accentuate the positive, and simply ignore the negative. There are enough sites that encourage negativity and even vitriol. This is not another of those sites. Items that are popular with scrum masters will rise to the top (click the Most Popular icon) and those that are less so will not—although you may be more inclined to follow the recommendations of your favorite agilists than to go purely on popularity. Some people have a knack for finding unusually inspiring items far outside the realm of “Agile”.
How you can help
- Create an account: add resources or endorse existing ones. What has inspired you recently? Please tell us about it.
- Tag existing resources to hep others find what they need. This is quick and easy and will be very helpful.
- Socialize this site to your LinkedIn, Facebook, Twitter, etc. network. Perhaps add a link on your blog or website.
- Mention it in workshops, training courses, etc, and share your own personal url with your students and clients.
- Offer copies of your own book as giveaways. This will both encourage use and provide a wider readership for your work.
- Suggest sponsorship to companies or Agile groups you work with.
- Make a personal donation to support our running costs. This doesn’t need to be a great amount. It all helps.
- Offer feedback on your user experience and make requests to improve the site.
Learn More: AgileLib.Net?about
Imagine going to work at a software company and months later realizing that you haven't received any emails from your co-workers. Not a single person has sent you an internal piece of mail.
Flickr, CC The Commons
Your first thought might be to wonder if something's broken: maybe your email address was configured incorrectly, or there's an issue with your local mail client, right? At what point might it occur to you that the lack of emails was deliberate?
Most of us have become so accustomed to using email as a way to communicate and collaborate with our co-workers that we often fail to wonder whether it's really the most effective way to do things. Even when we do question email's efficacy, many organizations balk at the "radical" idea of giving it up -- much less replacing it with something else.
This week our friends at Flowdock, a Rally company based in Helsinki, explained how they use their own product and shared the fact that it has all but eliminated internal email. Flowdock is a team collaboration tool lets you communicate and track all the important stuff (threaded chats, code commits, Twitter streams, emails, and customer feedback) in one place. This "hub" feature is really important, because if your company’s like Flowdock you've got people using a mashup of applications -- from GitHub, DeployHQ, and Jenkins to Zendesk, Twitter, and Google Apps -- that together create a lot of noise. As Flowdock growth hacker Ville Saarinen explains, finding the signal in the noise is key to doing better work, faster:
"Using specialized tools over a general purpose one (like email) has huge benefits. They allow the team to share more relevant information, make better decisions, react faster, battle information overload, be less frustrated – and, overall, work more effectively. By adding a centralized hub (like Flowdock) to the mix, team members don’t need to constantly jump between these services to check for updates."
Flowdock offers a free, 30-day trial, and integrations with more than 50 common services means it plays nicely with the other apps you’re most likely to use. Sleek mobile apps for iPhone and Android let you get in the flow from just about anywhere, while emjoi support helps you put the fun back in functional communications. Already a Rally user? Log in with your Rally account and try it out for 60-days.
If you're drowning in emails and spending more time managing your work than doing it, don't waste time wondering if something's broken. Give Flowdock a try and get in the flow.Jenny Slade
I came across a very interesting timeline visualization the other day, as I was skimming Semiology of Graphics, the awesome book by Jacques Bertin. If you’ve been following articles on visualization in the Edge of Chaos blog, you might be familiar with it (see: My 12 Visualization Books).
This timeline shows how the actual and potential decisions and events have unfolded during the Cuban missile crisis in 1962. This series of moves, as in a chess party, is believed to have brought USA and USSR to the closest point of real nuclear conflict that threatened massive mutual destruction. The crisis was eventually resolved, and this visualization covers the whole story:
This mixed events-decisions timeline got me thinking. No doubt, the Cuban crisis does deserve to be visualized that way, with its hidden and/or possible threats and agreements. But I don’t recall ever seeing any similar mix of both events and decisions on a timeline anywhere else, neither in a presentation, nor in a case study of a project success or failure. There’s a bunch of visual techniques for decision-making, but it looks like there’s no common visual technique to facilitate a retrospective analysis of decisions bundled with actions.
For example, we can use a release timeline to reverse-track the points of ”Done” for features, and we will embrace the whole picture in one look. But what would we do at a release or a project retrospective, if we look at a timeline and see that our initial estimate for releasing a feature is very different from the actual release time? An events-only timeline won’t give any clues to stakeholders as to which decisions resulted in this late release. Hence, they’d have a lesser chance to improve them. Someone would look at a timeline in 6 months and think to themselves: “Hmmm, I can’t remember what happened, why we were actually that late with releasing this thing?” That’s where visualizing a sequence of decisions+events over time might come in handy. It’s worth noting that we are somehow more interested in “the reasons for failure” when at a retrospective, but this wording and thinking is hardly a good fit. We need to formulate this question in another way. Which sequence of decisions resulted in the delay?Focusing on avoiding mistakes takes our focus away from becoming truly exceptional
Well, it could be that taking such a grand look at a delayed project release is an overkill. Okay. Let’s then move a level up and see how visualizing decisions+outcomes will help in an even more serious stuff, such as analyzing a failure/success of a business, or a start-up. This article puts together 51 Start-Up Failure Post-Mortems. Ironically, the web page offers a context ad which says something like: “get data and trends on start-up failure”. I’d say the prevalence of data- and trends-based thinking is something that most of the failed start-ups have in common. With everyone having access to statistics and trends, it’s quite logical for the failures to be grouped by certain criteria. A successful start-up must have something more up their sleeve than data and trends. That would be spot-on decisions in their particular context, free from “join everyone else” mindset.
What I’m getting at is: if start-ups and established businesses had a visualization technique similar to the one used for the Cuban crisis, they would be able to take a deeper insightful look into the nuts and bolts of things. I presume that people who read the stories of failed or successful start-ups want to learn their lessons based on these stories, so having them visualized as a timeline with actual/potential decisions looks like a good idea.
I only hope that one day some start-up will get busy and come up with a timeline that would visualize not only events, but actual/potential decisions and their linkage with the events as well. This will give an excellent tool not for decision-making — there are zillions of visual techniques for that — but rather for a retrospective analysis of success/failure of a business, or a product release, or a PR campaign, or shooting a blockbuster, or staging a play. The practical applications are diverse, and such a visualization would facilitate the insightfully pragmatic thinking and successes, rather than failures.
*The highlighted quote is taken from the book Turn the Ship Around!: A True Story of Turning Followers into Leaders
Organizations strive to be lean with their development resources, but when stakeholders are competing for those development resources it can be detrimental to the organization. The key is to manage the flow of work.
How do you prioritize projects so that the organization is focused on delivering value vs. competing for resources?
You do it by running a Kanban at the executive level that feeds the team’s backlogs throughout the portfolio down to the nitty-gritty task level.Competing for Development Resources
I recently worked with a small company that builds mobile applications. The CEO of this company was very cash-flow sensitive and knew he needed to improve his organization’s predictability as well as productivity. As he read and heard about Agile, he was exposed to some of the common metrics that accompany the Agile “sales pitch” and related “high-performing team” concepts about improving efficiency by 500% and increasing team morale, among other benefits. These revelations and a genuine desire to empower his teams with tools to be “high-performing” convinced the CEO to drive his organization toward the use of Agile techniques.
After several leaders in the organization attended CSM and CSPO classes, the team restructured into “cross-functional teams” consisting of Web, iOS, Android and API developers to focus on building an integrated product for their customers (which usually have a Web component and iOS/Android applications). Sounds good, right? He did not have enough QA people to place one on each team, so they formed a separate QA team with a follow-on “hardening Sprint” strategy to test deliverables. Not perfect, but common. The company had ten major clients managed by three sales people. They tried to align one sales person to one development team to minimize churn and focus the teams on building products for a smaller set of clients. At first blush, it’s not a bad first attempt at structuring to foster cross-functional teams focused together on a set of products.
Each team had a backlog attached to it, which ran back to the products and clients that the team supported. The backlog started with high-level Epics defined by the Sales team members with Stories broken down by the team members. The goal of each Sprint was for the team to focus on one “product suite” for a customer (which would deliver the Web, services and mobile applications). Any guess as to how successful the team was with that goal in an environment where one team supported the goals of three different Sales team members?
The result, within a few Sprints, was a Sprint backlog jammed full of multiple stories from multiple products for multiple customers (lest any of the three Sales reps not see progress on “their sale” for one or more Sprints). Chaos quickly ensued with a development team in constant context-switching mode. Less time was given to Story decomposition to deal with the chaos and “ramped up” cadence. More time was lost to chasing down the details of Stories. It felt busier than ever to the teams, but looked less productive than the old “Waterfall” approach of the past to management and Sales. Everything was a #1 priority, running late, delivering with quality issues. What had Agile done? Obviously this company couldn’t do Agile if they wanted to manage their cash flow or maintain a sustainable pace of growth. That was the thought of management, anyway. It sure didn’t feel like 500%+ increase in productivity – Agile must be a failure.
The team was frustrated. They were doing everything right – writing User Stories, doing Sprint Planning, Daily Standups, Demos and Retros. They were practicing two week Sprints. They felt busy. They saw progress. They tried to estimate better each Sprint and to buffer for the “unexpected” to accommodate changing requirements from customers or from discovery. But they, too, started to wish for the “good old days” of a structured Waterfall plan and date-driven handoffs. The self-organizing teams, lighter burden of documentation, ability to manage work more closely themselves just wasn’t worth the pain of feeling constantly stressed out and disappointed – a far cry from the goal of “high-performing.”
What would you do in this situation?
What I would suggest you start to do in this situation is to create Epics at the Sales level for each Client/Product and run them through a Kanban based on priority of several criteria such as time-to-cash-flow and other strategic measures (such as those that may be used for identifying recurring business, strategic relationships, etc.) – manage the backlog of work to what the company values. I’d even suggest that you start with just one based on Cash Flow. This Sales-level Kanban becomes the feeder queue for the development team’s backlog, limiting work in process, improving prioritization across the entire Sales (revenue-generating) organization and helping to identify the bottlenecks in the ability of the organization to deliver. Conversations about injecting new “Epics” (e.g., a new Product for a new or existing Client) would have to happen up at the Sales team and executive level before it ever affected the delivery teams. Each Sales Rep would have a chance to say, “Look, I’ve got this work in flight or slated for work. If you want to add a new Epic it is going to cause this work to go on hold. Tell me how that is good for the company.” Discussions around Cash Flow, priority and commitment are elevated to the right level of the organization. We’ve put Sales in a position to justify and prioritize every Sale – before it affects our development/delivery team. This will allow the organization to prioritize their limited resources around what is most valuable. The world of managing expectations, contracts and sales would need to evolve around this, but we’ve implemented a mechanism to focus on Cash Flow with a limited capacity. Metrics at this level would allow the organization to make a real case for managing expectations at the current capacity, model revenue/cost options to increase the capacity of the teams and make decisions about the long term.
Now, some of you are about to take me to task about changes you would make to the team structure. I would make changes, too. But I’m not going to focus on those for the purpose of this blog post for a few reasons. First, I believe that making changes solely at the team level in this environment would have been of no value at all without solving the problem of managing the flow of work across the organization. Second, the alterations to the structure of the delivery team really aren’t mine to mandate; sure, I would make some recommendations and present some thoughts, but the Agile Coach in me wants to go back to having the team inspect their capabilities, adapt the structure to what makes sense and self-organize around owning future iterations of the structure.
To solve the underlying problem, the first step is to get Sales to make decisions around priority based on key business drivers (in this case, cash flow) in an environment of limited capacity. Remove the competition for resources, set the team up for less context-switching, and begin to identify bottlenecks, opportunities for growth and limitations in the system to be resolved over time. The flow of work improves, the metrics to measure progress (and needs to support growth) begin to emerge. The team is able to focus on delivery based on priority at the organizational level (as opposed to in-fighting and negotiating with three or more Sales Reps about whose sale is more important to get attention in this or the next Sprint).
Can it work?
Yes. Here is another example of a company who had product managers fighting for their development resources. This organization had sixteen developers working across forty products. There were forty product owners fighting for sixteen developers. We created a product owner team with a chief product owner. This created a “product funnel” by which the ideas and needs of the other thirty-nine product managers had to go through the chief product owner to get development resources.
With that construct, they were forced to govern the portfolio based on the prioritization of the organization, coupled with release planning, balancing capacity and demand. It was an extremely uncomfortable situation because the product management organization was always committing to many times more work than they could actually do. As they started to measure the entire portfolio of need against the ability to deliver, they came to the realization that there was capacity to support only 10% of what they wanted to deliver in their current state. Imagine, as a Senior VP of Product, seeing this reality in numbers – the pain of seeing the reality that your capacity is only 10% of what you need it to be. Imagine the pain, but imagine the power… what to prioritize, what to work with the Technology team’s leadership to do to improve capacity, what to communicate to Sales’ leadership in terms of setting customer expectations. Was it painful to force this portfolio-style plan and force the organization to prioritize work together? Absolutely. Did it present problems that seemed insurmountable? Yes. Was the team able to solve the problem of capacity and eventually deliver the wants and needs of all 40 Product Managers? Yes.Conclusion and my challenge to you
Agile is more than just Scrum. Agile is more than just cross-functional teams. Agile is a system of managing work and continuously improving that system to manage the flow and delivery engine behind that work. It’s about more than just the people; it’s about the system itself. If you are struggling with Agile for reasons akin to those mentioned here, I hope I have inspired you to take a look at how your organization prioritizes projects and how you manage disseminating the prioritized work to your development teams. If you are not managing a Kanban portfolio board, I challenge you to do it (whether it is on sticky notes on a board, Trello or some more sophisticated tool, just do it)! If you are good at prioritizing across the organization or are running a Kanban at the portfolio level, how can it be improved?
Now it’s your turn! What are some other ways you have improved prioritization?
The post With Limited Resources, It’s About Flow – Not Competition appeared first on LeadingAgile.
One of the things I emphasize in my executive engagements is the need to focus on measuring results rather than expectations, since expectations tend to focus more on operational adherence rather than value delivery.
Couched within this conversation is the idea that Agile is not just about efficiency, it’s also focused on effectiveness (value delivery). After all, what good is a process/method that helps you to do what you do faster/cheaper, but ultimately fails to deliver more value to your end users? Agile, therefore, offers the promise to both decrease costs and to increase revenue.
So, if your emphasis, and maybe your sole reason for choosing to go Agile, is to be more efficient, you will likely see the results you expected; your stuff is going out the door faster. But, if this excludes a focus on increasing revenue/value (i.e. product results), then ultimately you’re really just delaying the inevitable death of your organization. No amount of cost reduction can make up for a lack of revenue production. This idea may suggest that what we produce is more important than how we produce it, but I’ll leave that for another discussion.
Dave Gunther, a colleague at VersionOne, pointed out that process tools don’t really measure product results, and I’m not sure they should ever attempt to do this directly. However, if we view the “efficiency” or process/operational side of this equation as a product (something that attempts to solve a customer problem), then we may be able to find something of value in our process worth measuring.
Consider “pirate metrics”, which offer 5 key metrics to consider for a subscription based business model. Ultimately, these are focused on increasing revenue, which is the final metric. Here they are:
Basically, each of these metrics build on the previous one, so, if you aren’t increasing your acquisitions, then there is no way you will increase your activations, therefore you won’t have increased retention, referrals and ultimately no increased revenue. Or, another way to look at it is that you may have received a referral, which is good, but if you aren’t actively tracking how you came to receive a referral, you don’t have very good chance at recreating that result.
Eric Ries, in his book The Lean Startup, posited that we make guesses on what will actually turn these metric “dials”, and so proposed that instead of investing a bunch of money to fully develop our “assumptions”, we would be better off implementing the scientific method to prove, or rather disprove, them. For example, if you were actively measuring acquisitions, then, hypothetically, every option you choose to implement to your product would affect that measurement. This being true, then we can compare the results of each option to each other to determine which options best get us to our goal of increasing revenue (i.e. value). Essentially, this process is an A/B testing model.
With this model as an example, if we apply it back to the operational/process side of Agile Transformation, what would we consider to be our metrics? Would the revenue equivalent be velocity (I know, don’t compare!)? Would acquisition be equivalent to number of people trained in a boot camp?
What do you think these measurements should be? How do you measure the value of your process options, or do you even measure them at all? Please leave your comments, I’d love to hear what you all think.
.. or how agile manifesto has put a stigma on writing, and how this stigma backlashes on the culture of learning.
In one of my previous articles I’ve explored the roots of agile movement, and the mindset that guided the founding fathers of agile manifesto. The manifesto had this as one of the principles: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In the environment that existed 10+ years ago, when developers wanted to break free of the documentation associated with bureaucratic procedures, it seemed very reasonable to introduce and to follow that principle. It turned out, however, that the ardent followers rushed to the other extreme, and any other writing than that of code, or of user stories has rather been regarded as waste. No doubt about it, face-to-face conversations rock within a development team, and this principle is very appropriate in this context. But here’s the catch: if a principle is copy-pasted to a group of similar but still different situations, this might result in some negative side effects.
That’s exactly what happened to writing. With this inherited stigma of bureaucracy and waste,writing things down might look like an optional topping on an ice-cream. Why write, if everything can be discussed? I want to tackle such attitudes in agile teams and highlight tremendous benefits that the culture of writing brings with it. I am not talking about group chats, or problem messages, or technical documentation. What I mean is writing to express a thought, or an opinion, or to share the thinking behind some decision with the rest of the team in a logically coherent piece of text.
If keeping a library at a softdev company and reading is a #1 way to broaden horizons and balance technical competence with the other sciences related to software development, writing is #2. Talks and discussions are only #3. Why is writing so uniquely rewarding? On the one hand, it comes across as a tool that helps to hone logical thinking and express ideas with clarity. Speaking in a discussion as in a meeting is a spontaneous communication, an unprocessed feed of thoughts, that lacks the fine polish that is required to make a point. In contrast, lawyers are trained to have an excellent command of spoken rhetoric — the art of building a logical discourse to convince others. It’s the essence of their profession.
IT people do not seem to be that sharp with rhetoric skills, unfortunately, and they “owe” this to the technical focus of their education. I’ve written more on that in the article The Origins of Big Data Trend. Writing will fill this gap; the more someone writes, the more fit they become for speaking. Somehow, most people believe that the reverse is true: first comes speaking (and they do talk a lot), and then writing. It’s not like that. Being a good writer comes prior to being a good speaker, so if someone likes to talk but cannot write, might be that this person wastes everyone else’s time in meetings (unless they use the services of speech writers, which is unlikely).
With thoughts carved in the written form, people get better at sharing what they have to say, and eventually become better speakers. We also become better thinkers, because we start writing with one mindset, and then shift to another one in the process. Writing helps turn on the lights that highlight a problem from many perspectives, which is more likely to result in an efficient solution. When thoughts exist only in someone’s head, they are ethereal and scattered. Once neatly stacked, either on screen or on paper, they acquire discipline.
Now, suppose someone is aware of all the treasures that writing brings with it, and wants to champion this culture in their company. How can writing be practiced, in which form, does it have to be pushed on each and everyone? Of course, not. Some people in your team might not be ready to write yet.
We need time to accumulate the critical mass of knowledge that will want to find an outlet. There’s one tip as to how to define who is ready for writing, and who is not. Many use social sharing these days, so if someone in your team tweets links related to a problem at work, this person might be ready to venture out and share thoughts in writing. Such people need to be encouraged to write; throwing links will not take them far in expressing their own thoughts and ideas. There’s one other important thing. If writing is a part of company’s culture, then writers will need their peers as readers. Posting to an internal company blog comes first, then there can be a public blog. Posts can include logical discourse pieces that explain how this or that technical or strategic challenge was resolved or can be resolved; stories that software developers usually share in forums; essays and insights about company culture, what can be improved, what’s hot, etc. Sky is the limit. From the learning perspective, it doesn’t really matter what people write about. What matters is how they write and how their thoughts and ideas resonate with readers.
I’ve outlined five potential costs of delay in the previous five posts:
- The delay from not releasing on time, part 1
- The delay from multitasking,part 2
- The delay from indecision, part 3
- The delay from technical debt, part 4
- The delay from other teams as part of a program, part 5
The real problem is this: Why should you care? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)
Let me show you two pictures. The first you’ve already seen, the back of the napkin, where you see the effect on your potential maximum revenue.
Now, let’s try to calculate that cost of delay.
The longer your delay, the more your cost of delay moves your curve to the right. The more sales you lose out of the Maximum potential sales.
The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales.
That’s right. Do those numbers start to look big and scary now?
You not only have aggravation and impediments in your current project from the delays from multitasking, technical debt, indecision, slowdowns from other teams, you lose the potential revenue from maximum potential sales, every week you don’t release.
Now, I am not saying you should release horrible product. Goodness knows, we have enough of horrible product that barely works or doesn’t work at all out in the field. I want to see great products! The idea behind this picture is so people understand that it is worth their while to consider change.
You can change to shorter projects and release something useful faster. (See Manage It! Your Guide to Modern, Pragmatic Project Management)
You can change to agile or incremental lifecycles so they can see progress and release something useful faster. (See What Lifecycle? Selecting the Right Model for Your Project and Manage It! Your Guide to Modern, Pragmatic Project Management for an in-depth discussion of lifecycles. You have more options than just waterfall and agile.)
You can adopt a more reasonable approach to the project portfolio, and make decisions more frequently. (Does anyone really think project portfolio decisions last a year? Come on.) (See Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects)
You can consider paying off some technical debt. I used the build system in my example. I could have used automated tests or the thousands of defects some of you have in your defect tracking systems. It’s whatever prevents you from knowing you could release on a “moment’s” notice. I would like that moment to be under an hour. I bet for many of you, less than a day would be a huge improvement.
You can optimize for the entire project or program, not their feature or team. Too often, I hear, “My part is done.” That does not matter. It matters what the entire team, project, or program finishes.
In my talks about project portfolio management, I am fond of saying, “It doesn’t matter how many projects you start, it matters how many you finish.”
With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.
I have taken a high level approach to cost of delay in these posts. I wanted to simplify it so you and I could understand it, a zeroth approach, if you will. If you want more information, start here:
Cost of delay is why you cannot take an ROI or use date or budget estimates to manage the project portfolio. This is why you must use value. I look forward to your comments.
Agile systems provide better predictability, progress visibility and collaboration, but many organizations fail to realize the benefits throughout their entire organization.
They are applying a single process, intended for development teams, across executives, program managers and developers.
To fully realize predictability, progress visibility and collaboration through Agile, you need separate Agile systems to manage responsibilities and accountabilities that are different for each role.
What are the separate Agile systems?Un-Separate Agile Systems
Most technical teams that I see running scrum have a pretty good system for delivering technical work. It’s reasonably well documented with respect to governance and policy what you do during a sprint planning, how you commit to the work, how you get the work done, how you do a demo, how you do a retrospective. What I see less often is a product management policy governance and cadence that is both disciplined and systematic.
In most organizations I work with, the product managers and technical teams are locked in conflict. Either the product manager is unhappy because he or she has to decompose work into small enough pieces for the technical team to deliver on it, or the technical team is unhappy because they have to build products against great big specifications, and they’re not delivering exactly what the product manager asked for.The Conflict of Un-Separate Agile Systems
The conflict comes from organizations using work items that serve two separate sets of responsibilities and accountabilities. User stories are the sole unit of value of delivery, and they’re the sole thing that a product manager has to accept as value. Those same user stories are the unit of work on which you have to understand all of the technical items you have to deliver and the accountability around which you think about quality in the artifacts that you deliver.
This creates a conflict between batching and size. The size at which value starts to matter to the customer could be on the order of weeks’ worth of work. At the technical delivery level, the notion that you would take one batch of work and spend weeks on it before you deliver it to your product manager creates a conflict of wandering. You’ll get off path and won’t deliver the right stuff. A user story or decomposition from a feature to a user story creates a situation in which you’re delivering small units of value. Product managers can see value in the user stories that you’re delivering because they show progress and represent learning against their bigger unit of value, but delivered to an outside customer or consumer, they wouldn’t be valuable.
You break the conflict by creating small units of work for technical delivery that are then composed back into the larger unit of work that can be delivered to the customer. You need separate Agile systems to manage responsibilities and accountabilities that are different for each role.Responsibilities & Accountabilities of Separate Agile Systems
I find what works best is separate systems for separate goals in the organization. Executives are responsible for allocating budgets and selecting projects that they believe are going to achieve their investment goals. The responsibility here is allocating the investment and selecting the business cases. The accountability is tracking that the business cases are meeting their individual financial goals and tracking that the overall portfolio is meeting the financial goal of the business.
At the program level, the responsibility is taking a business case and turning it into what you need to do in order to meet the goals of that business case, including the financial objectives, customer objectives and functional objectives. The accountability is validating, accepting and taking full accountability that you get what you asked for.
At the delivery level, the responsibility is detailing how you’re going to do something and creating a full understanding of that. The accountability is ensuring the quality and fitness of the artifacts that you produce. The definition of done in all those levels has to directly relate to the accountabilities of those levels.Language of Separate Agile Systems
When you’re managing a portfolio, you’re in the language of executives, which means you’re talking about visions, goals and investment allocations. You’re selecting opportunities from your portfolio of investments in terms of business cases. That is the language of the executive. I have a vision, I have a goal and I have business cases that allow me to attain that goal.
For example, let’s say you have a four-way split on your investment allocation due to government regulation. Your going to invest 30% of your budget and you expect a 0% return on investment. You also have a 25% investment in keeping the lights on, just maintenance of the product. 55% of your investment is sunk cost. The other 45% has to make up the 40% margin you expect from your investment.
When you think about the program level, you’re thinking about the flow of value. In flowing value, you have units of work that are value oriented, and a container of value. You may call them a feature. So a business case from the portfolio level might be that you want to invest 300 thousand dollars in a new virtual infrastructure. As you flow value, the first bit of value might be that I have to research three different kinds of virtual infrastructure stacks so that I can make a build buy decision.
You may have features called research cloud stack, research open stack and research VMware. When those are all done, you actually have value that you delivered with those because you have learning, and now you have a third unit of value, which is making a decision. That’s flowing value.
At the delivery level, you’re flowing the technical work, delivery or artifacts. At this level, you talk about user stories and tasks. I recommend your tasks and user stories start with a vertical slice of the application, or a vertical slice of the knowledge and learning that you want to do, and they flow through the steps so that the other side will have an artifact.
When thinking about how work flows, each level will have a unique and contextual set of steps needed to transform an idea into a deliverable. At the delivery level, you might talk about code, code review, unit test and testing. At the value level, you might talk about functional analysis, technical analysis, build it and accept it. At the very top level, you might talk about ideation, committed and tracking. The flows are different. The languages are different. The purposes are different.Separate Agile Systems Portfolio Level Agile Systems
The top level system, the executive system, develops why you’re doing a particular piece of work and that why takes the form of goals and initiatives, portfolio management and investment.
It typically begin with investment themes and allocation. I’d suggest you use something similar to the following: we intend to capture new markets with 10% of our budget, keep the lights on and maintain the project with 60% of our budget and we intend to do less risky but high value projects with 30% of our budget. Those are your overall investment themes. For each theme you define what qualifies as something to be involved in your investment.
Once you understand your investment themes, you should go through a selection process. What business cases should you select? Once you know why you’re doing something from an economic or benefit point of view, then you should dive into the details of your business case. Ask yourself or team what benefit it has to your customer and company, what it’s going to cost, what the constraints are, and who the stakeholders are.
What you are creating is a cascading set of artifacts and processes that are dependent upon one another. Once you have selected a set of business cases, you need to determine the why, division and goal. Those selected projects move into a program level where you start to manage the overall program that has been selected. That system has a different flow focused on delivering value.Program Level Agile Systems
Now that you know why you’re doing something, you need to know what it is that you’re building. Not how you’re building it, not the specific technology and artifacts you’re going to deliver, that comes later, but what you’re building and what functionality, user experience and feasibility you need from these features to meet the executive goals. This is the point you begin due diligence to determine if you should buy or build and start advocating and selling the business case.
Now that you have a business case, you need to decompose it into units of work, called features. You need to understand those units of work functionally. This is where you draw pictures on white boards, take pictures of drawings, create a conversation about the units of work and conduct analysis. Once you understand the units of work’s functionality, you begin discussing the technical feasibility and high-level designs of the units of work.
Once you understand the technical feasibility of the units of work and have agreement and shared understanding, then you’re ready to decompose them into user stories that a delivery team, or a technical team, can start to work on.Delivery Level Agile Systems
This system focuses on the construction of artifacts and the delivery of actual artifacts, as opposed to the program management system, which focuses on the delivery of value. This might be something like detailed technical design, coding, code review and manual testing. Once all of the stories that are related to a particular feature are done, then we have a unit of value in the container of a feature and that feature can be accepted by the product manager, or the product management team, which says, “Yes, this is the value that we accepted.”
Business cases flow down through the systems in the form of responsibility. At the portfolio level, responsibility is allocating investment and selecting projects; at the program level, responsibility is developing what you’re building, how you’re going to build it and dictating artifacts; at the team level, responsibility is delivering quality artifacts; then, at the most outer level, responsibility is tracking the return on investment, value proposition and the business case to make sure the value that you intended for the customer and business are being realized. Those three Agile systems have to be separate.Summary
I hope this article has inspired you to reflect on whether your organization has a conflict between the goals of the program managers and developers. If you do have this conflict, I would encourage you to write down how your organization gets from a great big idea to knowing what you’re going to deliver for that idea. Write down the steps that you take, and the policies you have around those. This is the first step to separating these systems and fully realizing predictability, progress visibility and collaboration through Agile.
What ways have you experienced conflict between the goals of executives, program managers and developers?
The post Keeping Everybody Happy with Separate Agile Systems appeared first on LeadingAgile.
Sprintly is excited to announce yet another awesome integration! Today we feature the Raygun.io integration from our friends at Mindscape. Raygun notifies you of your software’s bugs as they happen. With this integration you can attach an error group to a Sprint.ly issue that already exists, or create a new item in Sprintly from an error group. All directly from within Raygun. Read more about the integration here on their blog.
Why do we need a library?
In a recently published article ( The Origins of Big Data Trend) I’ve pondered on the reasons and consequences of why software developers find themselves locked in the narrow technical mindset, and how this affects business and technology trends, for better or for worse. When someone only knows how a second leg of a centipede makes a move, and has no idea of what makes the whole centipede glide on all its 100 legs, they will be at a loss in the face of unexpected new challenges. Software development craves for more people with a broader outlook. That’s why it’s in the best interest of IT businesses to encourage the culture of learning with their employees. If formal education fails to provide this well-rounded knowledge, we need to invent our own ways to catch up. Reading appears to be the most obvious catch-up strategy.
The culture of continuous learning has always been nurtured in our company. It starts with hiring: we only welcome people who are genuinely interested in learning, and have curious minds. We learn, explore, share knowledge, do internal conferences, and one of the things that supports this culture of learning is an old-school library of paperbacks in the office. This tangible library makes learning easier. If you see all those books every day, it’s hard not to stop by and not to skim through a book, or two, or three. We do not have a formal curation strategy, as to who is supposed to read what. If someone wants a book — the book is ordered, and that’s how our TauLibrary has been formed. It has 300+books and counting.
How do we manage books in the library?
We use Targetprocess, our project management tool, to track the circulation of books. There’s a project called “Library”. When someone wants a book, they create a user story and put it to “Please order” state. The next state is “Ordered”, and then there’s a state called “In Stock/Reading”. If a book is assigned to someone, the assigned user is currently reading it. If a book is available in the library, no one is assigned.
Here’s how the books look as a list of user stories:
.. and broken down by some tags:
Which books do we have?
The library has books on management, agile, lean, kanban, testing, programming, machine learning, artificial intelligence, continuous delivery, statistics, mathematics, data science, psychology, linguistics, philosophy, writing, marketing, SEO, design, visualization… Ufff. What else? I find it hard to categorize all those books that we have. Tags might do this job better than me. Perhaps, there’s even no great need for categorization. Software development is a fusion of many disciplines, that’s why developers need to know what visual arts and cognitive sciences are about; designers need to get an idea of what developers are doing; marketing people will want to learn more about data science and visualization. Everyone has to catch up in some field of knowledge. Reading is the very first step, what goes next, depends on individuals. Either way, a library is the low money investment with a huge return on a company’s ability to innovate. Ultimately, all things learning transform to innovations. The spirit of innovation will reveal itself in the way people think, get insights and discover subtle perspectives of looking at familiar problems. If the culture of learning became mainstream with IT companies, I’m sure this world would have a lot more friendly, nice and usable software products.
Most IT companies use job descriptions listing technical skills that a candidate should be proficient in. With these lists taking the bulk of the description, little or no attention is paid to personality traits. At best, they mention something along the lines of “listening and communication skills” or “outstanding skills in working under duress and the ability to influence across all levels of the organization”. I want to try to put those fuzzy requirements into simpler terms, and this is unrelated to formal selection criteria. It’s hardly possible to formalize the very first personal impression a candidate makes on the interviewers, although this impression does matter a lot. This is about simple things that we feel on the gut level. It’s whether you like someone, or not; whether you want to see this person in the office every day, or not; and sometimes we are not even able to put in words: what is it exactly that makes us feel aversion to someone, or to like someone.
I’ve written on that previously: teams are happy when they do the work they like in the company of people they like. So, which people do we like? It has little to do with technical expertise.
We like sunny persons who are sincere in their manifestations and have nothing to hide in their attitude to fellow workers. This personality trait is called integrity. As opposed to that, there are people who appear to have several versions of their self; and they turn them on depending on the social situation they find themselves in. The switcher between those versions is often based on some personal biases or fears, and this internal dividedness is somehow felt by others.
We also like people who are problem-less. I doubt that anyone wants to spend much time with a person who is always ready to grumble about something. Most of the conversations such people casually start are looping around complaints on how life is hard, or how rain is too wet, or the sun is too hot, or how their meal tastes like crap today, etc. Someone with such an outlook on life is more likely to approach work in the same way, and even an easiest move might be a problem for such people. Professional challenges need to be addressed matter-of-factly, with “just do it” attitude. The habit of grumbling and complaining makes life and work much harder. Not to mention that it’s a huge energy waste.
Then, we like people who are smooth. The quality of smoothness is the one that helps most in keeping the productive flow of co-workers. If we have to deal with folks, who are not taking valid arguments and obstinately stand their ground , this is a tough challenge. One stubborn person might throw some sensitive types off track, as those sensitives would choose to shut up, only to spare themselves the trouble of confronting stubborn attitudes.
Sharing a company of people that we like plays up not only to little idiosyncrasies. IT companies pay much attention to technical infrastructure: computers, servers, all things hardware and software. Co-workers form a human infrastructure, the peopleware, that is as essential to the work outcome as the technical one, if not even more. The goal of any infrastructure is to facilitate productive flow. The less bumps in routine interactions, the more energy can be put into creative work, the stronger the flow. That’s one of the reasons royal courts and other venues hire masters of ceremonies, whose job is to keep the flow of an event or a show uninterrupted. We don’t have masters of ceremonies, but cherishing each other’s flow and keeping the company of people we like is entirely in our powers.
Work in software development is made up of 2 essential parts: planning and doing. It stands true for any methodology, be it agile or lean or any other variety thereof. The theory of project management has it, that a project can accommodate 10-20% of time spent on planning, tracking, adjusting trajectory, wiping the binoculars, etc. At least, we used this approximation when I worked in an outsourcing company many years ago, and it varied depending on the challenges the project was facing.
With projects, this world has only 2 options for anything else than doing:
Option #1: the bulky “talk-plan-remake-do it again” cycle is a given.
Option #2: over-indulgence in all things talking and planning is a waste.
The hardest job is to distinguish if a project falls into option #1 or option #2. If the option #2 is disguised in the make-up of a given, developers and other performers will feel troubled about whatever they’re working on. When someone has a job to do, all they need is to be left tete-a-tete with their work, and as little contacts with the outer world as possible. If a stretch of work — be it during the day, or over longer periods of time — is interrupted by previously overlooked hurdles, the drive to ship is replaced with something like this.
The unwelcome “talk-plan-remake-do it again cycle” usually happens if planners are not directly involved in the ship-deliver activities, and lack foresight in tracing the hurdles in advance. For the actual performers, being subjected to all kinds of catch-up moves feels like a huge annoyance. Performing is a raw and healthy thing. Some software developers naturally feel more inclined to performance-based activities, and their philosophy is: “I care only for what I have to ship, and I don’t want to mess with the waste of talking.” If we draw a parallel with performance on stage, the feeling after having shipped a piece of work would be akin to this: I’ve worked my a.. out, I’m sweating and exhausted, but I’m happy because I performed and delivered the show that people liked!
There’s nothing as fulfilling as a happy experience of a well-accomplished performance, and performers find delight as they ship something on any given day. All the tiny dwarfs in the world run a round of applause at that. The deliverable can be a piece of code, or those few milliseconds of faster load times, or a finished design element, or an HTML-coded web-page. If it feels like too much unwanted planning and discussing that undermines this desire to perform, your team is in trouble. This feel signals that the whole act of planning is misinterpreted, and is seen as a thing-in-itself that lives in isolated reality, unrelated to a shippable outcome. Besides, it’s a proof that the keepers of “talk-plan-remake-do it again” routines lack competence in nailing down the optimal solutions at the right time. If that’s what’s happening in your organization, remember that talkers and planners are not the rainmakers. Performer is the rainmaker, and planners would be better off if they let performers perform, or better yet, get to performing and doing rather than talking and planning. The catch here is that with time some sort of organizational blindness might develop, as talkers and planners manage to come across as rainmakers. Beware that optical illusion.
Sprintly is excited to announce the Bugsnag integration. Bugsnag detects and diagnoses crashes in your applications and now you can set up Bugsnag to automatically create defects within Sprintly. Read more about Bugsnag and the integration on Bugsnag’s blog!
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Most folks have heard the old adage that you never discuss religion or politics in polite company. Frankly, I’m guilty of both because I think it’s fun and I can take it. As a society, I think it’s time to consider a third category of zealotry that needs to be banned from our fancy dinner parties… agile methodology.
You’re probably wondering now what it’s like to go to a party with me, and why the hell would I be talking about agile at dinner for anyway… but that is beside the point. The problem is that some of us can’t seem to talk about agile without getting really upset and taking disagreement way too personally.
The past few nights I’ve been entertaining myself by posting controversial topics on my Facebook page. My goal is to see if we can spin up some lively discussion. Last nights topic was on the minimum wage in the US and the role of government in controlling such things.
People have very strong opinions about these topics. Many folks come at the discussion from the position of social justice and doing what’s right. Some approach it from a systems perspective and the impact such controls have on society. Some believe a free unregulated economy should determine the prices on goods and services.
What was interesting about the discussion, and I was really trying hard to facilitate a discussion… not a debate… was how personally people connect with these topics. It’s not some abstract political discussion, it’s about the people we know, our families, and how we perceive the world around us.
Religion as you might imagine is even more difficult. How do you have polite conversation about what you believe about God? It transcends the academic and moves into our soul. Questioning my faith isn’t about examining historical facts, it’s about the very foundation of my belief system.
Often, religion has a huge role in how we were raised as children, the relationship we have with our parents, our social structures, and how sure we are about the afterlife or the lack of it. It sets the tone and the underlying foundation for how we view the world around us.
Folks have a hard time distinguishing between a simple academic discussion and a personal attack on who I am as a person. The issues strike that close to our core.
Sometimes I feel like we get this way about agile… at least those of us that live, breath, and eat this stuff. Those of us who are zealots about one methodology or the other. Those of us who write books, publish blogs, and tweet incessantly about the topic… we are all pretty strongly opinionated.
Sometimes the conversation isn’t really about the merits of my methodology against your methodology… it’s more personal than that. It’s more about my perception of the world (and my place in it) in violent opposition to your perception of the world (and your place in it).
It can tie into issues of economic security if my business is built around one approach or the other. It might trigger ego issues if I happen to be heavily invested in one particular approach… as either an inventor or well known thought leader. It might just be that my experience simply isn’t your experience.
Many of us have a lot of experience and we’ve seen lot’s of stuff work. What I find absent from many of the online conversation is context. We are so busy arguing about what is right, what is wrong, what works, and what doesn’t… sometimes I think we forget that all of this stuff has worked in one context or the other.
Personally… I have made waterfall work beautifully at scale. I have made textbook RUP work. I have made Scrum, XP, RUP, and Waterfall hybrids work. More recently we’ve blended Scrum, XP, and lean program and portfolio governance into dynamic, situationally specific models for our clients… and it works.
I tell my clients quite often that most everyone they’ll talk to in this space is a consultant. We all have a point of view, we all have something to sell. Sometimes having something to sell get’s in the way of doing the right thing, or even going off message for the sake of the clients success.
I’d love to see more of our conversation start with context. What did you experience? Why did you experience it? What was it about the context you were in that led to your choices? What were your constraints? What worked? What didn’t? What would you have done differently next time or in a different context?
Wether it be religion, politics, or agile… I think some genuine desire to understand each other, and each other’s perspectives, would go along way to more constructive dialog and more meaningful outcomes.