XP is the Mac of Agile by The Agile Warriorhttp://agilewarrior.wordpress.com/2014/02/03/xp-is-the-mac-of-agile/
"When Apple released the Macintosh it changed the face of computing. Graphical user interfaces, drag and drop icons, clickable menus. Since it's release, the personal computer has never been the same. The same thing happened with the release of XP. Like an earthquake, it shook just about everything we traditionally believed and practiced in software delivery down to it's core. And then both failed."
"In this article [Jonathan Rasmusson] would like to explore why Scrum has become so popular, the challenges this popularity brings to Agile, and why, like the Mac, [Jonathan doesn't] think we've heard the last of XP."
"One reason [Jonathan] believes Scrum has grown so popular, is because unlike XP, it struck the right balance between maintaining the status quo and change."
… read more … http://agilewarrior.wordpress.com/2014/02/03/xp-is-the-mac-of-agile/
Mistakes in pursuit of curve-jumping innovation are an unavoidable part of the agile process and investment. Some organizations are afraid to allow Dev teams to make mistakes (or experiment with change) and they build engineering cultures that discourage risk-taking or the trying of new things. These cultures ultimately limit opportunities to build competitive business advantages and put their business at unnecessary risk in changing markets. Consequently, mistakes are a necessary component of innovation. That being said, the best Dev teams only make new mistakes.
What do I mean by “new” mistakes? Developers in challenging situations come up with a “new” idea. The idea appears “new to them” because…well it is new for them. However, there is a pretty good chance that some “variation” of this “new idea” already exists and that there may be a thing or two that has been learned along the way…which might be beneficial to consider.
Innovative and visionary developers should assume that “new” ideas have been tried before. Therefore, they should invest a quick moment to search for existing engineering insights, ready-to-use assets and/or feedback data that might accelerate the effort or improve the quality of their craftsmanship. When Dev teams stop repeating mistakes and only make “new” mistakes, organizations experience faster failures AND faster successes – leading to greater innovation and competitive advantages. It may sound like a contradiction but actually it isn’t.
Encouraging developers to make “new mistakes” (and capturing the valuable learning data) leads to:
1) Acceleration of uniquely brilliant innovations for your business,
2) Reduction of time / efforts in subsequent development projects
3) Improvement of current and future product quality, and
4) Enhancement of engineering craftsmanship (especially for agile teams working in smaller and faster moving isolated local groups, and it’s incredibly helpful for future developers joining these fast moving teams).
To achieve these goals, organizations need to adopt agile best practices and craft (or invest) in an engineering friendly system of Continuous Improvement that helps agile development teams make corporate benefiting NEW mistakes, once. Collaborative environments and systems that capture engineering successes and failures help fast moving (and constantly changing) local agile teams support the organization’s desire for faster innovation in their changing markets.
Are you interested in discussing what a corporate system for collaborative development might look like for your distributed organization? Would you be interested in hearing about enterprise organization stories that have seen 80%+ Reductions in project related costs, 70%+ Improvements in Time-to-Market efforts, 65%+ Increases in Dev productivity, and dramatic improvements in meeting security, compliance, and governance obligations. The teams and partners I work with would welcome the opportunity to talk about what an ideal Continuous Improvement software development system might look like for your:
1) Organizational needs,
2) Industry governance or compliance obligations,
3) Engineering practices (Agile, Waterfall, Scrumfall, etc.),
4) IP identification, security and protection strategy, and
5) Future visions of process efficiency (e.g. Continuous Integration, Continuous Delivery, Deployment Automation, DevOps, etc.).
Let me know if this is something you would like to explore further.
Paul Peissner, Agile & DevOps Enthusiast
The post Continuous Improvement – Helping Agile Teams make NEW Mistakes appeared first on blogs.collab.net.
I’ve been at Sprint.ly for four months, and what better way to celebrate than with a little reflection in the form of a blog post! As those who read my initial “welcome” post know, this is my first official job as a developer. Though it took roughly two years of web-hacking and self-hacking to put myself in the position to get hired somewhere like Sprint.ly, I’m still in shock that I’m actually here now.
For all this, the highlight of my first few months hasn’t been learning a new language or library; it’s not crystallized in a particular pull request, and has nothing to do with overcoming a particular set of fears (though that’s pretty awesome too). The real highlight of my tenure so far at Sprint.ly has been finding my way into a team of people who care deeply about the product we build, and who care deeply about each other’s success. I’m lucky to work with more seasoned developers who, without having to ask, will take time out to explain technologies that I may not even directly work with, and I never feel like I can’t ask any of my fellow developers a question, or expect to get a thoughtful answer when I’m stuck on something new.
Choosing to be a developer is committing to a lifetime of learning—and there’s a shared understanding here at Sprint.ly, and as we become part of the larger Quick Left team, that we can all help each other to be better craftspeople. If this sounds good to you, take note: we’re hiring!
Kate Terlecka is an an agile coach and a Professional Scrum Trainer. She wants to change something in the way people in Poland make software, so she founded the Brass Willow initiative, which is bringing together experienced trainers, coaches and technical experts who want to do something more. Kate blogs about Scrum, Lean and Agile at Control Your Chaos. Here’s Kate…
Combining Kanban and Scrum – lessons from a team of sysadmins
Lately, Ken Schwaber’s post about Kanban, strongly stating that it’s not a good way to follow, stirred up Scrum, Kanban and lean worlds. Let’s not take any side here and take a closer look at these two approaches collaborating.
Kanban itself is ultra light. You can pretty much enclose it in one statement: visibility & limiting work in progress. Sounds nice and lean. I see a huge problem here – this is not enough. Kanban is so light, that it does not provide sufficient guidance for teams adopting something different than cascaded development or guerrilla-style support. I have teams not able to cope with coming up with the whole process themselves. Because in this case, the team has to come up with:
- A way of gathering requirements
- Guarding the process
- Solving problems with team growth
- Conveying business value
- Reporting future projections
- Handling finance issues
- and so on …
Coming up with all of this would take huge amount of time & effort which then is wasted, since the team is not productive. And we cannot introduce a manager, since then self-organization will not occur. This is asking for waterfall-like top-down process control. I guess I can understand Ken Schwaber’s doubts about Kanban now.
But what about teams that do support work? They are unable to plan their sprints. Like for example system administrators, infrastructure providers and so on. It’s good if the development team is supporting their own tools, but there has to be someone that provides rack space for this team. There are also teams that are supporting sunsetting products, so they are only fixing most critical bugs, before the product will be forgotten or replaced. They are also unable to use Scrum, since they are unable to plan for a week (but they tried).
Some time ago, we tried to combine Scrum and Kanban. I always oppose when someone uses the word Scrum when they are not using Scrum, so this approach was named Kate-Ban . We took what we needed from the Kanban approach and dragged everything else from Scrum. Let’s see how it worked out.
There were a few initial issues – the team was not cross-functional. There were Windows sysadmins that supported laboratory network and Linux sysadmins that supported working network and connections between sites. Due to security policies, these two sub-competencies would never fully mix. Windows guys had some basic knowledge about Linux environments, but did not have access to all parts of them and vice versa. In addition, there were around 1700 customers for this team, so determining order in the backlog was no easy task. This also made it very difficult to track ad-hoc work, which was later estimated for 50% of the total capacity. Of course ad-hoc work in this case meant 10 minute problems, like creating an account, not bugs to be solved in under a day – that was solid work.
The board was designed like this:
Queues (green lines on top)
There were two queues – the Linux and the Windows one. People were pulling elements from queues according to their order – the ones in the bottom-right corner were most important. Whoever was able to take a task, could take it. Mainly Linux admins were taking Linux tasks, same with Windows, but it wasn’t a rule. Who could complete a task from front of each line, pulled it. Both queues were limited to 10 elements, rest was kept in a Product Backlog.
Competency groups (yellow lines)
Each group had a limit of 4 tasks to be taken in total (having three people) and in addition there was a QR task in each group. QR was pretty much being a firefighter and taking the smallest stuff. It was critical – based on what the QR was doing, new tasks were added to the line, helping automate this role as much as possible. There is also an on hold zone, for tasks that got stuck due to external interference.
Done & rejected (red lines)
Done was cleaned up whenever it filled up. Rejected were those tasks, that suddenly were not needed, or after little investigation did not make sense.
So, this was all there was from Kanban. Now, it was Scrumified.
There was a Product Owner, who was taking care of the Product Backlog, and producing tasks for the board. It was his job to make sure there is always enough to do on the board, but not more than 10 in each queue.
There was a Kanban Master (me ), who was taking care of the process, making sure that the board looks neat, takes care of the team development etc.
There was a Definition of Done for few types of tasks, that had to be followed.
Every week there was a Grooming session – one very technical, one customer-oriented.
Every two weeks there was a Retrospective, unless called for earlier.
There was a Review, called by the Product Owner whenever a logical part of functionality was completed, maximum every two weeks.
There were Daily Plannings – a combination of Sprint Planning and Daily Scrum – a two-tier half hour meetings by the board, where the team accepted new elements in queues, planned their next 24 hours and briefly reviewed completed work.
No Deadlines. In Scrum, Sprints were providing the heartbeat, the moment when the work was inspected, certain feedback – there was nothing like this in this setup, so after some time, for most critical tasks and the ones that were on the board for too long, the team started adding deadlines.
Having no regular feedback loop also enabled some people to slack off, start doing something else in the meantime and it went through undetected for quite some time.
In this case, this team had an excellent Product Owner, but it would be easy to change this from pull approach to push in an instant.
Since it was too hard to estimate in this environment, tasks were not estimated. Product Owner was projecting from the amount of tasks alone, not from their size. It was working surprisingly well with such a various environment. I guess that Jim Highsmith is darn right, calling for forgetting velocity. Let’s look at it later though.
The story of this team was unfortunately abruptly terminated due to a series of unfortunate events. It was later replaced with some people that decided only to follow some of those rules, but it’s not working very well.
A team that used Scrum before, or at least tried and gets all its benefits and drawbacks is able to adopt Kanban on the Scrum canvas. A team that is supposed to be self-improving only by being given a statement with three rules in it has vague chances of success. Kanban is an excellent toolbox, but it needs a well-composed set of tools to be really useful.
This post originally appeared as Combining Kanban and Scrum – lessons from a team of sysadmins in November 2011. Thanks, Kate, for contributing it!
A programmer, writing some new code, looks into some existing code that she needs to use. Something doesn’t look quite right. In fact, there’s a bug. Whether no one’s triggered it, or they have but their complaints haven’t reached anyone who will do something about it, is hard to say. Can she fix this code now and keep working? Or does something prevent that?
In such a situation, I would prefer to write a new test illustrating the bug, fix it, and check both the test and the fix into source control. This might take five minutes or an hour. It’s a small detour, but I feel better knowing that the code is now safer for the future.
Maybe, however, there are policies, either explicit or tacit, that prevent such quick resolution.
Perhaps there is a “ticketing” system that requires opening a formal change ticket before introducing a change. That can slow you down. It might also make it more difficult to do if you’re already working on a different change ticket for the new code you’re writing.
Perhaps someone else is the “owner” of this code, and you need to ask their permission before fixing it. Perhaps you even need to ask them to fix it. If they’re busy working on other new code, you may wait a long time. The change may seem unimportant to them.
I’ve often seen organizations that lock down their “architectural framework” code on the assumption that only their most senior developers can be trusted to work on it. Asking that something in this code be fixed might require writing up a formal justification and submitting it to an architectural review board for consideration in their monthly meetings. Perhaps before making any change you need to create design documents and get them approved. Perhaps a committee needs to come to consensus on what design is best.
Perhaps various teams have to analyze what effect the change will have on their code. To do this, they’ll need to check what assumptions their code is making. If these assumptions aren’t encoded in automated tests, this is a difficult check to make.
I’m sure there are other ways to slow down or discourage fixing broken code, but these are common ones I’ve seen.
Why is this important? If it’s easy to fix the code, programmers are more likely to fix it. If it’s hard, they may ignore it and leave a bug waiting to happen. After all, nobody will point a finger at them about a bug they happened to find and then ignored. So, bugs accumulate.
Even if the bug is important enough to brave the work of bringing it up, the delay is intolerable. They may have to program a work-around, a patch in some other place to compensate for the bug. With good intentions, this is meant to be temporary, but after a long delay, it’s hard to go back and correct this. Such patches further degrade the code design, making it harder to program and easier to create bugs. It puts behavior in unexpected places where people won’t think to look if it’s causing problems. It also creates surprises that programmers won’t expect if they’re reusing the code where the patch was hidden, causing further bugs.
I do not believe that you can prevent mistakes. The strategy I’ve found to work is to make it easy to notice and correct them. Beyond that, think about the underlying causes and try to make similar mistakes less likely in the future. But give up on locking things down to prevent mistakes.
There are now three ways to attach files in Assembla - from your computer, via Google Docs, and now via Dropbox. The new integration conveniently allows you to select and share Dropbox files with fellow team members, and since Dropbox takes care of versioning, the most recent version will always be available to your team.
In this release, the Dropbox functionality is only available in the Files tool and when attaching files to created tickets. We are actively working on expanding the functionality system-wide. Until then, here is how you can start using the current dropbox integration:
1. Select ‘Add Dropbox File’ from the list of file controls to expose the Dropbox ‘Choose File’ button.
2. When you click on ‘Choose File,’ you will get a Dropbox pop-up. If you are logged into Dropbox, you will automatically see your dropbox folders and files. If you are not logged into Dropbox, you will be prompted to login. Once your folders and files are in front of you, select the desired file from the pop-up and click ‘Choose.’
3. The selected file will be displayed. You can optionally add a short description and/or labels. Click ‘Upload File’ and team members will now be able to access the shared Dropbox file.
If you have any questions, comments, or suggestions, please leave them in the comments below. Stay tuned for more improvements coming your way soon.
Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development.
One of my managers many years ago had a back of the napkin approach to cost of delay.
“Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.”
I got it.
There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point.
We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it.
We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because the cost of not shipping on time was too great.
When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Take your delay in weeks, and remove the revenue weeks. That’s your cost of delay, back of the napkin approach.
You can go through more serious calculations. Troy Magennis of Focused Objective talks about a “compounding impact” on other projects. I am sure he’s correct.
But even if you said, “Every week we slip, we lose at least a week of revenue from our maximum sales week of revenue,” do you think people would notice?
How do you release on time? You fix scope (ha!). You have release criteria. You have shorter projects, because they are easier to estimate and deliver. You use an incremental or an agile lifecycle, so you have more predictability about your release.
This post is the simple idea of not shipping on time. But what about when you have competing projects and not enough people? Look for Part 2, next.
P.S. After I wrote this post, I realized I was not living this post. (Why do you think I write? It’s not just for you. It’s for me too.) I published the incomplete Essays on Estimation. I have another essay or two to release. But if I don’t release it, you can’t read it and get any value from it, can you? The point: if you don’t release your products, your customers can’t get any value. Hat Tip to @jlottsen who said in a tweet, “you have to release it, or no one can use it, and you can’t realize any revenue at all”. Very true.
First of all… this is a really, really, really big topic. If we are lucky, we’ll get a start and maybe lay a foundation for future conversations. My goal in the next 1000 words or so is to at least introduce the foundational concepts, and frankly… help me see where I want to go with this. So… with all my pre-qualifications in place, let’s see what we can do.
Over the last few posts, we’ve talked about what it takes to do Scrum well and explored many of the anti-patterns that cause Scrum to fail. One of the biggest challenges to adopting Scrum is the ability to form complete cross-functional teams. Before we get into how to solve the problem, let’s first explore why it’s so hard to begin with.
First of all… let me share that I have NEVER worked on a small agile team. I’ve coached many of them, but my introduction to agile was in the context of large enterprise class financial systems… things like online banking and bill payment. The kinds of systems where the company makes a penny or two on every transaction and does millions every year.
Think about what it takes to build these kind of systems. Quite often you had a hundred or so people involved… maybe more. You are dealing with a very diverse technology stack. At the time, we had people building software in .NET, Java, C, and Cobol… interfacing with an Enterprise Data Warehouse, leveraging web services, PeopleSoft, and any number of other systems.
To make things more complicated, quite often the systems we were building were actually systems of systems. Not just in the Systems Engineering sense of the word, but actually products of products where the product we were building was made up of other products, each with their own customers, product management, and deadlines.
Our job was to introduce changes in these systems, not break any of the other existing functionality, make sure we delivered on time, without getting in the way of anyone else delivering on time. Needless to say, these were pretty complicated delivery efforts and required tons of analysis, architecture, and business sponsorship across the entire organization.
All said, the core team of folks was maybe 100 people or so, but we were interfacing with an organization that all said was at least 400 people.
Okay… so now think about the guidance that we give for the formation of a Scrum team. A cross-functional group of 6-8 people that have everything necessary to deliver a working, tested, increment of the product. How in the world would I get 6-8 people with the skills necessary, the understanding of complex workflows, and the domain knowledge to touch this many systems?
I’m not suggesting that it’s *impossible* to do this, but I’ll tell you… most products have not been built with the underlying architecture, test harnessing, or continuous integration necessary to even take a stab at shared code ownership across such a diverse stack. At some point, the lack of sub-system level ownership would very likely erode the integrity of the overall solution.
Even suggesting this would be incredibly risky proposition and likely a non-starter in most organizations.
So where does that leave us relative to forming Scrum teams? The idea of feature based teams in organizations building these kinds of systems, at this level of scale, is not practical guidance. If you can form a team like this in your environment… stop reading now and go do it. It is clearly the simplest way to go. If not, you have some work to do to figure this out.Forming Capability Based Delivery Teams
Most organizations can be viewed as a series of capabilities. A product is effectively a capability. A feature set within a product can be a capability. Services that support multiple products can be a capability. Things like accounting, and finance, release management, and deployment can be capabilities. Performance testing and integration can be capabilities.
At the team level in any organization, rather than getting hung up on the idea of the cross-functional feature team, the idea is to form Scrum teams around capabilities. The capability based Scrum team operates just like any other textbook Scrum team, it’s just that their output is a capability that can be consumed by other capabilities within the enterprise.
Capabilities as defined here tend to have pretty well defined inputs and outputs, contracts and service levels with the rest of the organization. They typically rely on a less diverse technology stack and the level of domain knowledge necessary to iterate the product is less relative to the entire system you are trying to build.
The comparison we like to make here draws a parallel between refactoring a legacy architecture into a services oriented architecture. The goal is to get each of the services loosely coupled and highly cohesive. Similarly forming Scrum teams, we want each team to be loosely coupled and highly cohesive… just not necessarily responsible for an end-to-end slice of the entire product.
That said, if you think about it… we might just have a semantic argument at play. One man’s product is another man’s service. So from the point of view of the Scrum team, they are building a product… it’s just that the product is a service that can be consumed by the rest of the organization… building blocks if you will… that the enterprise software is based upon.Forming Products From Collections of Services
The problem with services oriented teams is that, more often than not, our customers aren’ buying services from us (although sometimes that actually does happen)… it’s our internal product organization that is consuming the service. In this case, you may very well have a traditional Scrum team formed around a product or feature set of the product consuming the output of the services teams.
In this case, these Scrum teams operate more like a textbook Scrum team. They have a backlog, meet with the Product Owner, and produce working tested software every sprint. But get this… by definition, these teams wouldn’t have everything necessary to actually deliver the software, they are dependent on the services in order to create an end-to-end slice.
Here is an interesting insight…
The problem with this scenario, isn’t that the product team is dependent on the services team… the problem is that the product team and the services team are both delivering their backlog at different rates and potentially at different times. When an end-to-end feature requires both teams to deliver their piece… we create a planning dependency between the teams that is difficult to manage.
I’m clearly jumping into the governance conversation here a bit… but it’s these planning dependencies that are killing large scale agile adoptions. You can go the SAFe route and try to get everyone into the room to work out an integrated release plan. We’ll often do something similar but leverage a smaller group of people, running features through a Kanban system.
The idea is that we’ll manage requirements decomposition through a Kanban, but have queues to batch requirements into sprints or releases if the organization isn’t ready for a continuous flow delivery model. Either way, the challenge remains… when you have a large, multi-team system, it’s very likely that you’ll find bottlenecks in the system. Some teams will go faster than others.
The problem with bottlenecks is that one team races ahead building services while the product is struggling to make forward progress. Quite often, it’s the products that are able to race ahead and the service creation that struggles to keep up. In both scenarios, you end up effectively with partially complete code that no one can use.High Cohesion and Loose Coupling
To alleviate these problems between teams, we come back to the idea that teams must be highly cohesive and loosely coupled. That means that we should avoid at all costs committing to features that require more than one team to be done in the same place at the same time in order to make an integrated delivery.
Maturing agile enterprises, need to move toward a model where the product teams and the services teams operate on their own individual cadence and are able to deliver software at whatever velocity they are able to commit. In practice, this results in three rules for team-to-team interaction in a large enterprise.
1. Product teams can only commit to delivering features based on services that currently exist. This is the least risky approach.
2. Product teams can commit to delivering features based on services that are on the near-term services roadmap. This carries some risk, but is usually pretty manageable.
3. Product teams inject dependencies, by requiring a service be created while the feature is in flight. This is the highest risk scenario and should be avoided if at all possible.
Basically, Scrum tries to solve the dependency and bottleneck problems by requiring each team to have everything necessary to deliver a working tested increment, asking each of the team members to serve as specializing generalists, and having people swarm on backlog items to get done and stabilize velocity. I totally agree with all of this, it’s just not practical at scale.
We’ll explore this more when we talk about governance… but for now… let’s recap where we are.
Large organizations often can’t implement the idea of a complete cross-functional feature team. In these organizations, Scrum teams need to be organized around capabilities, products and services that must be combined to evolve delver software at enterprise scale. The more effectively we can decouple the delivery teams from each other, the less planning overhead we’ll require.Product Owner Teams
I’ve been on record for quite a while that I believe the single product owner construct is a myth in most organizations. I get why this was created and why it should work. Without a singe voice of the business to give clear unambiguous guidance to the team, the team is going to thrash. The problem is that a single person with the necessary skills and authority to create the backlog don’t often exist in companies.
We’ve been a big fan of a construct called a Product Owner Team and implement this construct almost everywhere we coach. The idea is that to sufficiently groom a product backlog you need several points of view. We encourage the PO Team to have of course the product point of view, an architectural point of view, an analyst point of view, and a project management point of view.
I’m not talking about roles or people, I’m explicitly talking about the perspective brought by each of these disciplines, regardless of who actually does the work. When you are working in a methodology based on the idea of fixing time and cost, and varying scope to meet business goals… it requires more than just the business’s point of view to make the appropriate tradeoffs.
When we are working in a predictive-convergent organization… remember that concept… our job is to figure out how to solve relatively fixed business problems with somewhat pre-determined solutions. By having these four perspectives working together, you can make real time trade-offs about what to build and how to build it to optimize your chances of being successful.
I kept promising to tell you guys the story about my house… that would have illuminated some of my thinking here… but that will still have to wait for another day.Portfolio Governance Teams
Similar to the Product Owner Team structure, we find that many organizations need cross functional teams of leaders to approve the investment increments at the portfolio level of the organization. Depending on the size of the organization, this can be a team of directors and managers. I’ve implemented it as a team of the CIO, CTO, the VPs of Engineering and Marketing.
Most organizations have some sort of governance model in place… a phase gate model if you will. Again… we’ll talk more about this when i do a post on agile governance… but for now, just think about leaving your existing phase gate model in place, model it in a Kanban, run much smaller batches through the system, limit WIP, etc… you get the picture.
For the same reason I like cross-functional teams providing guidance on requirements decomposition, I like cross-functional groups of leaders providing guidance on how work is approved and flowing through the system. When delivery is blocked, the leadership team can see it, and help get the resources necessary to the teams to get things moving again.That Still Isn’t Everyone
At this point we’ve talked about teams formed to help work get approved and into queue to be built, teams of people that are responsible for requirements decomposition and high-level architecture, and teams of people responsible for building products, and different teams of people responsible for delivering services. What about the rest of the organization.
Some organizations have strategy groups, marketing, sales, integration, release management, performance testing, infrastructure, DevOps, SCM… and many, many others that I’ve failed to mention. Should we tuck these people into Scrum teams, or maybe disband these groups and let the Scrum teams do everything themselves?
That might work for smaller organizations… but again, in many of the large organizations we work with, these functions are necessary, and maybe even necessarily separate. For us, this is where the Lean part of Lean-Agile program and portfolio management comes in. It doesn’t matter so much how these teams work, if they use Scrum or Kanban or Waterfall.
What matters is that these teams agree to work with the other parts of the organization in small batches, limiting work in process, and reducing cycle time. At scale, there are going to be upstream and downstream groups that have to work together to get the product you’re building into market. Coordinating the delivery across those teams is the current problem de jour in the scaled agile discussion. I don’t believe that Scrum is the answer in these kinds of organizations.Summary
Okay… where does that leave us? When you are designing your agile enterprise… you’ve got to ultimately take into consideration how you are going to form teams, how the work of those teams gets coordinated, and what you are going to measure to know you’re making progress. We explored (in somewhat gory detail today) the structure side of the problem.
I tried my best to make the case that the notion of the cross-functional feature team will break down at scale. There is just too much subject matter expertise, too much domain knowledge, and too diverse a technology stack for one team of 6-8 people to build much of the large scale software that is getting built today.
If this is your reality, that means you’ll have to consider implementing Scrum teams based on products and services, or more generically, capabilities that can be reused across your organization. Governance is largely the way that work gets coordinated across these teams, but the more you can decouple teams, and have them work at their own pace, the more agile you’ll actually be when you are done.
Product teams and services teams don’t make up the whole of the agile enterprise. We have many upstream and downstream groups that have to be able to work effectively with the Scrum delivery teams to get the product into market. IMO… this is something that Scrum doesn’t have much to say about. SAFe is making a pretty good stab at it.
More generically though… the idea is to model the rest of the organization into a Lean/Agile value stream, run smaller batches through the organization, limit WIP, and work to reduce cycle time and reduce time to market. At scale, business agility isn’t about how effective Scrum teams are… it’s about how effectively the entire organization can get product into market and generate a return.
Hope this gives you guys some things to think about. IMO… this is the missing piece of the puzzle for many companies.
I usually try not to directly pimp our services when I write, but helping people solve this problem is a significant part of our practice at the moment. We use all sorts of techniques from interviews and collaborative sessions to a very structured approach called Capability Modeling that allows for structured conversation and results in a heat map of your organization that can be used, not only for forming teams, but for having conversations about the impact of changes you might want to make to your technology platforms. It’s proving to be a pretty powerful lever for making organizational changes at scale.
Good luck, let us know how we can help. Looking forward to your feedback.
Check out the next post, Shu Level Agile Isn’t The Same As By-The-Book Scrum.
Check out the previous post, Structure, Governance, and Metrics on Large Scale Agile Teams.
No vision is perfect, but sometimes the hardest person to convince of that is the visionary. Given that a shipped game rarely resembles the original detailed design document, an equally detailed and prophetic vision buried inside someone’s head can be just as capricious. A common result is that the emergent gameplay quality is not taken into account and teams become disengaged.
I call this dysfunction “tunnel-vision” product ownership. It’s common in studios transitioning from a design-document approach to an agile one. Although the visionaries admit that detailed design documents fail to create a shared vision, they haven’t yet adopted an agile mindset which requires:
- Frequent face-to-face engagement with developers.
- The ability of teams to produce iterations of an emergent game that validates the vision (or not).
- The ability of the product owner to evaluate their vision against the emergent game.
Parts on the Garage Floor
The product backlog become a component list of features and functions that are necessary to fulfill the vision…someday. This reminds me of someone building a prototype car, part-by-finished part. They build a carburetor, then the tires, etc. Eventually, when all the parts are built, an assembly phase is entered. Even if all the parts fit together, it rarely results in a very functional car (check out how cars should be prototyped - http://wikispeed.org/the-car/).
The same thing happens on games. The following practices are seen with the parts on the garage floor dysfunction
- There are too many component (or functional) teams. Examples:
- AI team
- Animation team
- Design team
- Graphics team
- Crunch sprints (usually called something else) with lots of overtime, little velocity or just tackle user stories created to address debt (refactors, bug fixes, polishing, etc). If most user stories don’t read like features users would pay for (e.g. I wouldn’t buy a game based on how many bugs the team fixed), it’s generally a strong indication that a good definition of done is not in place, teams are doing a lot of component work or debt is piling up,
- Team disengagement - Teams that don’t have a tangible vision or one that is months away from being realized have a hard time engaging in their work. This is especially true on larger projects. Nothing will drag velocity down more.
As with any cultural issue, tunnel vision is hard to fix. Transforming a detailed-design-document focused culture to one of frequent communication and inspection doesn’t happen overnight. There needs to be some bridgework between the two. Before the documents are shrunk, the product owner needs to gain skill in communicating vision and in learning to respond to the emergent game. To start with, I’ll find ways to improve communication in sprint planning, reviews and retrospectives. Establishing a better definition of done, and phrasing the sprint goal in terms of true value (e.g. “what are we going to be able to play at the end of the sprint”) sets the context for what is expected (in the playable game). Focusing the sprint review on the state of the gameplay sends that message as well. For the team, it’s easier: having a product owner responding to gameplay communicates priorities.
For the product owner, it’s more challenging. I encourage ScrumMasters to be diligent in asking the appropriate questions of the Product Owner in planning and review:
- Sprint planning questions:
- “What do you want to be able to do in the game by the end of the sprint?”
- “What should the player be able to experience by the end of the sprint?”
- Sprint review questions:
- “Does the game demonstrate the gameplay you asked for in sprint planning?”
- “Are these mechanics are as fun as we envisioned in sprint/release planning?”
- “Do we need to make changes to the release plan/product backlog to course correct based on what we’re seeing?”
- “What are the biggest concerns in making this game as fun as we envisioned for the release?”
- Sprint retrospective questions:
- “How can we decide earlier in a sprint if gameplay quality is achieving a vision?”
- “What can we do to achieve the litmus test of a gameplay mechanic earlier in a sprint?”
- “What parts of this game’s vision do the developers not believe in or have concerns about?”
It’s better to have a vision than none at all, but a vision must be tempered with reality.
After a massive weight loss, our database feels much better and our operations team is happier.
Until recently, Assembla supported 2.3 million wiki pages in our main database. This required about 30GB of data, prevented the database from fitting in the memory of the database server, and frequently affected the performance of all database transactions.
The arrangement was also extremely wasteful, because every page was included in full, even if it had only minor differences from a previous version. If a user changed a one character on a 1,000-byte page, the revised version would also require 1,000 bytes of storage, for a total of 2,000 bytes.
We realized that migrating the wiki pages to Git repositories would free up the 30GB in the database and speed up performance.First try
Since we already have an established process for communicating with remote Git repositories from our web app using the BERT-RPC (http://bert-rpc.org), we decided to see if that would be a good way to carry out the migration.
However, initial results were not promising. The process was very slow, because every Ruby worker is single threaded. Also, every commit to a bare Git repository, and every blob retrieved from a repository, required about 5 calls to a Git binary, which slowed performance even more.Git-ting it right
Our revised plan was to write our own RPC server using the Go programming language (http://golang.org), Git to go (https://github.com/libgit2/git2go) and libgit2 (http://libgit2.github.com). We also used MessagePack (http://msgpack.org) serialization format and its RPC capabilities.
With this RPC server on our development machine, the Go daemon was able to handle thousands of requests per second using a single OS thread (the default value for GOMAXPROCS). Increasing the value of GOMAXPROCS increased throughput even more.The migration process
We started by migrating the biggest wikis, some of which had hundreds of thousands of versions of the same page, and which totaled gigabytes of information. After running “git gc” compression, the biggest wiki was down to 98 MB.
However, InnoDB doesn’t release space after content is deleted. Therefore we did a complete database reload by dumping the database, removing the InnoDB data files, then restoring everything back. Our operations team was able to do this without any downtime.Healthier and happier
After this weight loss program our database is healthier and the Assembla operations team is happier. The new RPC Go daemon is a success, the database is no longer a resource hog, CPU and RAM consumption are much better, the team receives much less alerts than before, and our customers have fast access to their wiki pages.
Are you looking for the best Agile Methodology PPTs? Check out our the LeadingAgile list of the best Agile Methodology PPTs! We have scoured the web to pull together a list of the greatest Agile Methodology PPTs we could find. We hope you find these helpfully whether you are just starting your Agile journey or are well on your way and just looking for ways to improve.1st Agile Methodology PPT
Our first presentation was presented by Mike Cottmeyer and Dennis Stevens at the Agile2013 conference. The presentation explains how to create safety and visibility for management when doing an enterprise wide agile transformation.
Our second presentation was presented at the 2013 PM Symposium in Washington DC by Derek Huether. This presentation explains how to be successful with Agile at Scale by putting culture last and predictability first.How to be successful with Agile at Scale. 2013 PM Symposium from Derek Huether 3rd Agile Methodology PPT
Our third presentation is from Rick Austin. This presentation covers how to do story mapping and requirements decomposition.Storymapping presentation from Rick Austin 4th Agile Methodology PPT
Our fourth presentation was presented by Mark Kilby at the South Florida Agile Conference. This presentation discusses the five sources of conflict and various tools to help your team navigate it for better collaborationCollaboration Through Conflict – SFAA 2013 from Mark Kilby 5th Agile Methodology PPT
Our fith presentation is from Dennis Stevens. This presentations describes an approach to integrating Risk Management into Agile in the Enterprise.Agile and the nature of decision making from Dennis Stevens Summary
I hope you found these Agile Methodology PPTs helpful. I hope that if you are just starting your Agile journey these presentations inspire you to take the next step. If you are well down the path of your Agile journey, I hope these Agile Methodology PPTs provided you some ideas on how to improve.
What other types of presentations would you like to see?
ScrumMaster sind dazu da, die Produktivität ihrer Teams zu erhöhen. Gerade in Projekten mit hohem Erfolgsdruck ist diese Erwartung deutlich zu spüren. Vorbei die rosaroten Zeiten, als der ScrumMaster sein Team von den wirtschaftlichen Zwängen der Wirklichkeit zu befreien suchte. Das ist eine gute Entwicklung, denn sie gehört zum Erwachsenwerden dazu. Damit Scrum auch von Vorständen und Geschäfsführern ernst genommen wird, müssen ScrumMaster zur Führungsinstanz werden, auf die sich Top-Manager verlassen können.Nötig: ein eigener Führungsstil
Macht dieses Bild aus ScrumMastern bloße Erfüllungsgehilfen des Top-Managements? Verkümmert der ScrumMaster zum verlängerten Arm der Geschäftsleitung? Die Gefahr besteht immer dann, wenn der ScrumMaster zu schwach ist, um einen eigenen Führungsstil zu entwickeln. Dann ist er schlimmstenfalls das Sprachrohr anderer Leute – und dazu noch ohne disziplinarische Führungskompetenz.
Aktuelles Beispiel: Ein strategisch wichtiges Projekt, in das viele Ressourcen gesteckt wurden, steht auf der Kippe. Das Top-Management steht unter Druck und gibt diesen Druck an die Scrum-Teams weiter. Begründung: Allen beteiligten Akteuren soll klar werden, wie wichtig dieses Projekt und die Einhaltung von Lieferterminen ist.
In einer solchen Situation kann der ScrumMaster zwei Dinge tun: Entweder stellt er sich entschieden gegen das Management und versucht, das Team von dieser Drohkulisse so gut wie möglich fern zu halten. Oder er gibt nach und erhöht selbst den Druck auf das Team. Beide Optionen sind für die Legitimität des ScrumMasters fatal, denn er riskiert den Vertrauensbruch mit der einen oder der anderen Seite.
Gibt es aber eine dritte Möglichkeit – eine, die weder auf Gehorsam noch auf Rebellion basiert? Kann ein ScrumMaster die Erwartungen des Managements mit den Erwartungen des Teams zusammenbringen, ja vielleicht sogar versöhnen? Damit das gelingen kann, müssen ScrumMaster sich auf ihre ureigene Stärke zurück besinnen: Die soziale Bindung an ihr Team. Ein ScrumMaster ist nur in zweiter Linie Facilitator, Servant Leader und Change Agent. Primär ist er Teil des Scrum-Teams und sitzt damit mit dem DevTeam und dem Product Owner im gleichen sozialen System.Unbezahlbar: die großen und kleinen Gesten
Das eröffnet ihm ganz eigene Möglichkeiten, die nicht auf den klassischen Einflussfaktoren Macht und Geld beruhen. Die vielen kleinen und großen Gesten eines guten ScrumMasters – vom Bereitstellen einer wohligen Arbeitsatmosphäre bis hin zur intensiven Auseinandersetzung mit jedem Teammitglied – sie dienen allesamt dazu, eine Form der Transaktion innerhalb des Scrum-Teams zu schaffen, die nicht auf den Normen des Marktes, sondern auf sozialen Normen basiert.
Und hier liegt auch die Chance des ScrumMasters. Er kann sein Team mit genügend Selbstbewusstsein und Ehrgeiz impfen, dass es auch stürmische Zeiten erfolgreich meistert. Er schafft das, indem er die Identität seines Teams stärkt. Mit “Identität” meine ich ein Selbstbild, das eigentümlich genug ist, um das Team von anderen Gruppe abzugrenzen. Man kann in diesem Zusammenhang auch von Idiosynkrasie sprechen.
Ein Beispiel: Ich fragte neulich ein Teammitglied, warum er und seine Teamkollegen die Einladung eines (neuen) Kollegen ausgeschlagen haben, als dieser sie zu sich nach Hause zum Abendessen einladen wollte. Die Antwort war verblüffend: “Wir sind im Unternehmen die Außenseiter – wir versuchen erst gar nicht, uns beliebt zu machen.” Dazu muss man wissen: Das Team war in einem Projekt unterwegs, das allseits unbeliebt und von ständig wechselnden Anforderungen sowie Stillständen gebeutelt war. Das für dieses Projekt eingesetzte Scrum-Team hat den Lärm von außen ignoriert und ist seinen eigenen, oftmals rauen Weg gegangen. Dabei hat es offenbar eine eigene Identität – die des rebellischen Außenseiters – entwickelt. Damit war es erfolgreich: In nur sechs Monaten gelang es ihnen, gegen alle Erwartungen die Entwicklung zu einem glücklichen Ende zu bringen.
Als ScrumMaster habe ich vielfache Möglichkeiten, auf die Identität des Teams Einfluss zu nehmen: Das Review, die Retrospektive, die Dailies… das sind alles Happenings, in denen das Team Bilder von sich selbst produziert und dabei seine eigene Identität konstruiert. Als ScrumMaster kann ich im Sinne eines Stifters oder Förderers bestimmte Entwicklungen gezielt unterstützen und andere hinterfragen. Das hier genannte Team war zum Beispiel stets der Gefahr ausgesetzt, in Selbstgerechtigkeit und -mitleid zu verfallen. Hier konnte ich etwa durch paradoxe Interventionen dafür sorgen, dass mein Team die Bodenhaftung nicht völlig verlor. Auf der anderen Seite gab ich unserem Team reichlich Raum, um erfolgreiche Sprints zu feiern und jeden Tag den eigenen Weg zu bestärken. Hierzu ist es essenziell, dass das Team den gleichen Raum teilt und somit tatsächlich zusammenarbeiten kann.
Der Jahresbeginn eignet sich übrigens hervorragend dafür, um das Selbstverständis eines Teams zu reflektieren. Eine Frage könnte sein:
Was hat uns in 2013 stark gemacht? Und: Was davon brauchen wir in 2014? Was noch?
Siehe dazu auch:
- Führung in Scrum | Manager | Teil 5
- Der ScrumMaster als Coach im Heimatsystem
- RAUS aus der Komfortzone
It’s great when a product owner has a strong vision. It’s not so great when that vision changes daily. Some famous game designers have been known for this. They have a dream one night, or their cat does something interesting that sparks an insight, etc. Next thing you know, they are running through the studio excited about their new insight and impatient to see it being implemented. Unfortunately, this can have a bad effect on the team, game and business. There is such a thing as “too much change”. Change should include empiricism. The product owner needs to measure their vision against the actual game and not fall in love with their ideas alone.
Don’t get me wrong, I love enthusiasm, especially when it can be shared, but it needs to be combined with a focus on demonstrating fun in the game. Focusing on too many things that will somehow come together months later is a debt we don’t want to owe.