My manager reviewed the org chart along with the budget. “I need to cut the budget. Which resources can we cut?”
“Well, I don’t think we can cut software licenses,” I was reviewing my copy of the budget. “I don’t understand this overhead item here,” I pointed to a particular line item.
“No,” he said. “I’m talking about people. Which people can we lay off? We need to cut expenses.”
“People aren’t resources! People finish work. If you don’t want us to finish projects, let’s decide which projects not to do. Then we can re-allocate people, if we want. But we don’t start with people. That’s crazy.” I was vehement.
My manager looked at me as if I’d grown three heads. “I’ll start wherever I want,” he said. He looked unhappy.
“What is the target you need to accomplish? Maybe we can ship something earlier, and bring in revenue, instead of laying people off? You know, bring up the top line, not decrease the bottom line?”
Now he looked at me as if I had four heads.
“Just tell me who to cut. We have too many resources.”
When managers think of people as resources, they stop thinking. I’m convinced of this. My manager was under pressure from his management to reduce his budget. In the same way that technical people under pressure to meet a date stop thinking, managers under pressure stop thinking. Anyone under pressure stops thinking. We react. We can’t consider options. That’s because we are so very human.
People are resourceful. But we, the people, are not resources. We are not the same as desks, licenses, infrastructure, and other goods that people need to finish their work.
We need to change the language in our organizations. We need talk about people as people, not resources. And, that is the topic of this month’s management myth: Management Myth 32: I Can Treat People as Interchangeable Resources.
Let’s change the language in our organizations. Let’s stop talking about people as “resources” and start talking about people as people. We might still need layoffs. But, maybe we can handle them with humanity. Maybe we can think of the work strategically.
And, maybe, just maybe, we can think of the real resources in the organization. You know, the ones we buy with the capital equipment budget or expense budget, not operating budget. The desks, the cables, the computers. Those resources. The ones we have to depreciate. Those are resources. Not people.
People become more valuable over time. Show me a desk that does that. Ha!
In his short article “It’s time to split HR” Ram Charan proposes to split HR into an administrative department and a department for leadership and organization. His main point is that HR members need experience in other management functions such as i.e. finance. His criticizes that most of the current HR people cannot relate to business issues from the „real world“. I understand what his point is all about. People who study HR usually want to work with people and help them to release their potential. But this seems rather difficult as HR is mostly sitting in parts of the building with restricted access for “real world” people due to confidentiality reasons. The majority of them become experts in one specific field of HR (i.e. training, recruiting). Again, relating to business issues from the “real world” is rather difficult.
In an agile organization I would propose the ScrumMasters / agile coaches to take some of the HR duties. Mainly those that concern leadership and organization, but also, from time to time, administrative duties. Such a setup creates links to product development teams and their daily business issues. The ScrumMasters, being lateral leaders, know what it means to solve these “real world” problems – also known as impediments.
ScrumMasters are responsible for increasing the productivity of development teams. In order to reach their goal, they are supposed to change the organization as needed. Being involved in HR activities would be the perfect opportunity to create a link between the HR expertise and the “real world”. The adjustment of “People Systems”, as described by Jay Lorsch in the Strategy Pyramid, would be much easier. Also the other way round: the integration of the HR perspective into change initiatives would be given at any time.
What I also like about the idea of Charan is that HR is not a job position for life. Rather it should be a “pass through”, where one can gain experience in another field of management. In an agile organization this could mean that ScrumMasters and HR experts organize themselves in communities of practice. This way, they can work together and contribute to the success of the enterprise in different ways, for example like this:
- ScrumMasters could fill a full-time HR position for a certain period of time .
- ScrumMasters and their teams could participate as pilots for new concepts developed by HR.
- ScrumMasters could be friendly users for i.e. new concepts of leadership training etc.
- Engagement in different phases of the development process of new “people systems” is also possible (proposing ideas, defining the concept, collecting feedback etc.)
For a limited amount of time, ScrumMasters can be solely engaged in HR activities. Still it is mandatory that they return into leading a team after a certain HR deliverable has been released. An HR deliverable could be a new training, a cultural change that is clearly visible, new processes etc. But not only ScrumMasters can engage in HR topics, also other team members can take part in the communities of practice. How? The ScrumMasters and HR experts will find a way!
- Organisations need to understand …
- 5 minutes on management
- Massive Multiplayer Online Games the Digital Business School of the Next Generation
Arthur Carrera from Electric Cloud posted an excellent blog about the session that I led at the Agile Conference 2014 in Orlando. Here is a link: http://electric-cloud.com/blog/2014/08/who-killed-agile/
We traveled to Orlando, Florida last week for the Agile 2014 conference. It was a blast!
As Arizonans we are no strangers to the heat, but dry heat is an entirely different experience than being immersed in 80% humidity. Upon arrival in Orlando, we braced ourselves for the balmy weather and were much relieved to arrive at the Gaylord Palms Resort and Convention Center. For those of you who have never been, Gaylord Palms is like a biosphere: a temperature controlled, naturally lit, plant thriving oasis!
We were happy to set up in the expo hall right in front of the entrance doors. If you were there, there’s no way you could have missed us! We readied our booth with plenty of Axosoft swag – Scrum mini guides, Agile Notetakers, Tego Audio Nova speakers, and stress-ball ladybugs – then welcomed the first wave of conference attendees.
We had lots of great conversations with project managers, developers, Scrum masters, agile coaches, and the like. Many were drawn into our booth by our cute ladybug stress-balls representative of our recent decision to price Axosoft Bug Tracker at only $1!
With ladybugs in hand, people wanted to know what makes us different from our competitors. Many of you who are already familiar with Axosoft know that we are much more Scrum focused than JIRA, Rally, VersionOne and other Agile softwares. For instance, we have a new Daily Scrum feature that no other agile or Scrum software has to facilitate daily standup meetings. Lots of attendees started envisioning their teams using this feature.
People also loved our clean UI and many people stopped at our demos when they recognized our custom dashboards from the hit HBO show Silicon Valley.
All in all we had a great time talking to current and prospective Axosoft users at our booth. We were also happy to mingle with many more great people and even a mermaid! We came away from this conference with lots of great insights and ideas we will be bringing to Agile2015; hope to see you there!
Agile Chronicles – Composite Stories
Agile Artifacts – Ephemeral v. Enduring Value
During retrospection, when evaluating the quality and value of our artifacts for Epic, Feature and Story decomposition a common theme for our scrum teams is that these artifacts are by design barely sufficient and as such are ephemeral and provide no enduring value.
The design is in the code, the documentation is in the code, so we leave these artifacts attached to the engineering cards in our Agile Lifecycle Management (ALM) tool, close the cards when complete and never reference them again. Well, maybe we retain some Quality Assurance scripts that are still performed manually, but soon we will complete our QA Automation program and then the documentation will be in the code (automated scripts) and we won’t need to maintain a document artifact for QA scripts either. We accept this as a natural consequence of “barely sufficient” and we move on to the next sprint.
What if there was some undetected value in some of this information, and if sustained over time with minimal effort could provide enduring value, and help us achieve our team and business objectives.
Consider the case for managing software assets by creating and sustaining a definitive list of features for the software asset. This list becomes the feature dictionary, a common language for all teams and manifests itself throughout the Epic, Feature, Story life cycle.
Here is the brief story of an Agile Transformation and the value we discovered by performing software asset feature management and using that common feature definition to enable traceability for scrum team accountability, Quality Assurance test planning, code file ownership, portfolio analysis, competitive analysis and financial analysis.
We have just over 5M lines of code and the list of features began as a two-tiered description of 20 Capabilities and 70 related Features. The features were later delineated to 675 sub-features (about 10 sub-features per feature) to add more granularity to our traceability.
The driving business reasons for agile transformation were Quality first and foremost, but Predictability was also a problem that needed to be solved.
“We’ve done the PxQ analysis and if we dedicate two resources from each scrum team we can fix 700 defects in 9 months. We can do it in 6 months if we hire some contract resources”
Scrum teams were delineated by the list of features and corresponding software that they “own” and are accountable for. This enabled the scrum teams to focus on improving their knowledge of their software asset and focus on improving the quality of the software asset by allocating sprint time for refactoring and for reducing the technical debt that they inherited. Each defect was re-triaged in order to assign it to a specific scrum team for resolution, and as a result each scrum team had clear visibility to their defect backlog.
“You are fixing a few problems always breaking something else”.
Our client’s experience with our product was expressed as a negative impact to our business in the form of a declining Net Promoter Score and other reference-ability measurements. Participation in our client beta test program had dwindled to just a few long-term clients. The client pain manifested itself in the form of client incidents, some (or many depending on who you talked to) of which were caused by software defects. To reduce mean time to repair (MTTR), the scrum teams began providing recurring support in the form of team member rotations to the client incident triage process. They focused on resolving the incidents that were easily correctable without software changes quickly and were also responsible for assigning any defects that evolved to the scrum team that was accountable for the root cause feature set.
The predictability of delivering value to our customers depends on a well groomed backlog, how well we define the Epic that enables that value. The Epic is defined by the common list of features that are changed or added as a result of the Epic objective. This list of features per Epic is used to assign the features the accountable scrum teams, to elaborate the Feature modifications required for the Epic, define dependencies, perform Feature to Story decomposition and story point estimation.
“Why are we focusing our QA Automation efforts on an industry standard code coverage objective instead of focusing on defect hot spots and areas of code complexity? We need depth of coverage in targeted areas more than when need breadth of coverage for feature sets and features with minimal technical debt.”
Now let’s extend feature traceability to Quality Assurance (QA) scripts and to code files in the Software Version Management tool by denoting the QA scripts and code files associated with each feature. This enables the QA team members to plan based on the complexity of the feature changes to specific code files and to schedule the automated and manual testing that is necessary during each sprint. They can further verify this plan by relating the code file change reports produced in each of the build processes during the sprint to the corresponding features and Quality Assurance scripts. This enables the focus of QA feature testing to be (not limited to, but) focused on the specific and adjacent feature sets deltas in each code build.
“Why are we using our least experienced scrum team members and contract resources to fix defects in our highest complexity code?”
Next let’s study our software asset by analyzing the cyclomatic complexity of the code files. This standard McCabe evaluation provides some insight into which code files required subject matter expertise and extra scrutiny when the corresponding features were scheduled for delta in sprint planning. These dependencies were discussed during sprint planning, annotated in the ALM tool and scheduled for early resolution in the sprint.
“Why are we doing this, why are we adding or changing this feature of the product”?
Next, the scrum teams were encouraged to ask the product managers and product owners to explain the product vision so they could include that information in their respective sprint goals and release goals. The most important question to answer for the scrum teams was “why are we doing this, why are we adding or changing this feature of the product”? The answers were usually a rote response of “competitive response or competitive advantage”.
These recurring questions led the product management team to take a more proactive approach to answering this question and use the software asset feature list for quantitative and qualitative evaluation of competing and adjacent products. Our scrum team members were able to compare the specific feature sets for which they were accountable to the corresponding feature sets of competitive products. This was a knowledge accelerator for the scrum teams and most team members made it a priority to regularly assess these competitors for feature changes and shared this information during story grooming and sprint planning sessions.
Do we have a strategy for investment and are we executing it?
Over time, because we attached the feature annotation to all of the engineering cards in our ALM tool for our work on investments, enhancements, maintenance, and defect reparation we accumulated a lot of good information.
For each portfolio investment category and each feature set and feature, we had a near real-time and continuous flow of information, such as effort expended, story point investment levels, and defect hot spots. All of these measurements could be correlated to investment strategy, code complexity, QA coverage (depth and breadth) and competitor assessment. This information mostly confirmed, but sometimes indicated contradictions in our portfolio planning.
We used a 3-6 month portfolio plan horizon to rationalize future scrum team feature re-alignment, and impact assessments for near term investment spending adjustments, and budget constraints. The value and sight distance of this planning horizon was directly proportional to how well groomed our backlog was at the time.
So, to summarize the business value we received from software asset feature management:
- We initially used the feature list to define scrum team accountability, the features were related to code files in the software version management repository and team based access control was assigned for specific code files associated with the scrum team’s feature set ensured 100% accountability for all software changes to that feature set.
- Sprint Planning based on code complexity assured that the proper level of subject matter expertise was applied to high complexity software deltas in the form of team members with the most knowledge validating the work of less knowledgeable team members, and applying the commensurate the level of quality assurance effort, including increased depth of testing and more testing of adjacent features.
- The focus of quality efforts per build based on the features and code files that changed provided the optimal use of the limited QA resources of time and effort (even automated testing takes time).
- The competitive analysis information was new information to the scrum team members. It accelerated their knowledge of the product and made them active participants in continual market analysis.
- The portfolio view of accurate information enabled fact-based decisions for WIP and increased the accuracy and sight distance of our planning horizon.
The tangible benefits to our clients included:
- Much better results from our technical debt reduction program, and it got us out of the cycle of, according to our customers “fixing a few problems and breaking something else”.
- Most impactful was the renewed participation in our client beta test program and the willingness of the participants to express the value they received in terms of improved quality and feature improvements to other customers.
- This was reflected in improved client reference-ability.
The benefits to our software development organization were:
- Made our scrum teams much more knowledgeable of the software asset that they “own” in terms of complexity and feature value to the business.
- Provided a common language and some standardized practices for all scrum teams that improved the time to productivity for new team members by providing the Epic-Feature-Story-Code-File-QA-Script traceability.
- Enabled the scrum teams to understand the methods and level of effort required to produce zero defect software and made them realize that that was a realistic and achievable goal.
So in conclusion, having had this experience, we have agreed that each of these questions and approaches would be handled differently the next time.
“We’ve done the PxQ analysis and if we dedicate two resources from each team we can fix 700 defects in 9 months. We can do it in 6 months if we hire some contract resources”
Throwing money and resources at a quality problem will certainly fix many defects, but the incremental defect injection or leakage may go undetected.
“You are fixing a few problems and breaking something else”.
Believe the terrain, if your customers are telling you this then it is true and you have a problem that needs to be analyzed and resolved. Please do not rationalize it, as we did by telling yourself that “we are fixing far more defects than we inject”.
“Why are we focusing our QA Automation efforts on an industry standard code coverage objective instead of focusing on defect hot spots and areas of code complexity? We need depth of coverage in targeted areas more than when need breadth of coverage.”
Many of us have followed the rainbow trying to find the (mythical) 70% or 80% code coverage. Focus instead on incrementing quality where it will most impactful to your customers and business.
“Why are we using our least experienced team members and contract resources to fix defects in our highest complexity code?”
This was thought to be the most cost effective means of fixing a large number of defects in a short time. It was also the primary source of “fixing a few problems and breaking something else”. Apply subject matter expertise commensurate with the level of complexity.
“Why are we doing this, why are we adding or changing this feature of the product”
This is a non-engineering activity, but proved to have the largest positive impact to our team cohesiveness and culture. Understanding our product’s relative position in the market place made the team members cognitive of the value of the features they were building.
Do we have a strategy for investment and are we executing it?
This is two questions. The first is an easy one to answer. A strategy statement is easy to find somewhere in most organizations. Having a method to evaluate strategy attainment requires thoughtful effort to achieve.
See you on the journey!
The post Agile Chronicles (Composite Stories) – Agile Artifacts – Ephemeral v. Enduring Value appeared first on LeadingAgile.
I posted my slides for my Agile 2014 talk, Agile Projects, Program & Portfolio Management: No Air Quotes Required on Slideshare. It’s a bootcamp talk, so the majority of the talk is making sure that people understand the basics about projects. Walk before you run. That part.
However, you can take projects and “scale” them to programs. I wish people wouldn’t use that terminology. Program management isn’t exactly scaling. Program management is when the strategic endeavor of the program encompases each of the projects underneath.
If you have questions about the presentation, let me know. Happy to answer questions.
So there you are, wrapping up another successful release planning session. Sprints are all laid out for the entire release. All the user stories you can think of have been defined. All the daunting challenges laid down. Compromises have been made. Dates committed to. Everyone contributed to the planning effort fully.
So why isn’t everyone happy? Let’s check in with the product owner: The product owner looks like somebody ran over his puppy. The team? They won’t make eye contact and they’re flinching like they’ve just spent hours playing Russian roulette. What’s up? Well, here’s the dynamic that typically plays out:
- The product owner has some fantasy of what they think they will get delivered as part of the release. This fantasy has absolutely no basis in reality, it just reflects the product owner’s hopes for what he/she thinks they can get out of the team (it’s just human nature). This is inevitably far beyond what the team is actually capable of. My rule of thumb? A team is typically capable of delivering about 1/3 of what a product owner asks for in a release. That’s not based on any metrics, its just an observation. However, more often than not, it seems to play out that way.
- The team is immediately confronted with a mountain of work they can’t possibly achieve in the time allotted – even under the most optimistic circumstances. It’s their job to shatter the dreams of the product owner. Of course, strangling dreams is hard work. Naturally enough, the product owner doesn’t give up easy. They fight tooth and nail to retain any semblance of their dream.
- After an hour, perhaps two, maybe even three or four (shudder), the battle is over.
I’m going to go out on a limb here and speculate that this is no one’s idea of a positive dynamic. But it seems to happen pretty often with agile projects. It sure doesn’t look like much fun. I’m pretty sure this isn’t in the Agile Manifesto. So how do we avoid this kind of trauma?
- The product owner needs to be a central part of the team. They need to live with the team, be passionate about the product, and witness to what a team does daily. Fail to engage in any of this and a product owner loses touch with the work the team does and loses the ability to gauge their capabilities. Doing all of this is hard. There’s a reason that the product owner is the toughest job in Scrum.
- The team needs to embrace their product owner as an equal member of the team. You have to let them in. Work together. Let go of the roles and focus on the work.
- Prepare for the release planning in advance. There is no reason for it to be a rude surprise. Spend time together grooming the backlog together. As a team.
- Don’t cave to pressure from upper management. Behind every product owner is a slavering business with an insatiable desire for product. Ooh, did I just write that?
Release planning doesn’t have to be a nightmare. OK, in theory…
Filed under: Agile, Scrum, Teams Tagged: Agile, management, Planning, product management, Release Planning, software development
What does aggressive decoupling look like?
Last post I talked about the failure modes of Scrum and SAFe and how the inability to encapsulate the entire value stream will inevitably result in dependencies that will kill your agile organization.
But Mike… as some level of scale, you have to have dependencies? Even if we are able to form complete cross-functional feature teams, we may still have features which have to be coordinated across teams or at least technology dependencies which make it tough to be fully independent.
But Mike… you talk about having teams formed around both features and components… in this case, it is inevitable that you are going to have dependencies between front end and back end systems. Whatever we build on the front end, has to be supported on the back end.
What if you looked at each component, or service, or business capability as a product in and of itself. What if that product had a product owner guiding it as if it were a standalone product in its own right?
What if you looked at each feature that might possibly need to consume a component, or service, or business capability as the customer of said service who had to convince the service to build on it’s behalf?
What if the component, service, or business capability team looked at each of the feature teams as their customer, and had the freedom to evolve it’s product independently to best satisfy the needs of all it’s customers?
What if the feature teams could only commit to market based on services that already existed in the services layer, and could never force services teams to commit based on a predetermined schedule?
What if feature teams could *maybe* commit to market based on services which were on the services teams near term roadmap, but did so at their own risk, with no guarantees from the service owner?
What if feature teams were not allowed to commit to market based on services that didn’t exist in the service, nor were on the near term roadmap, eliminating the ability to inject features to the service?
I think you’d have a collection of Scrum teams… some Scrum teams that were built around features and some Scrum teams that were built around shared services and components… each being treated as it’s own independent product building on it’s own cadence under the guidance of it’s own PO.
There would be no coordination between the feature teams and the services teams because each set of teams would be evolving independently, but with a general awareness of each others needs. The services teams develop service features to best satisfy the collective needs of their feature team customers.
I’m not suggesting this something that most companies can go do today. There is some seriously intentional decoupling of value streams, technical architecture, business process, and org structure that has to happen before this model would could be fully operational.
That said, if you want to have a fully agile, object oriented, value stream encapsulated organization, this is what it looks like. You not only have to organize around objects (features, services, components, business capabilities), but you have to decouple the dependencies and let them evolve independently.
The problems ALWAYS come in when you allow the front end to inject dependencies into the back end shared services. You will inevitably will create bottlenecks that have to be managed across the software development ecosystem. Dependencies are bad, bottlenecks might be worse.
If we can create Scrum teams around business objects, work to progressively decouple these business objects from each other, and allow the systems to only consume what’s in place now, and never allow the teams to dictate dependencies between each other… I think you have a shot.
Do this, and you really have agile at scale.
I really enjoyed meeting new people and seeing so many old friends at Agile2014 in Orlando. Thank you to everyone who attended my session, asked questions and provided feedback, which encouraged me and gave me ideas for future events.
Here is the feedback for "Teaching Agile to Management":
"Your session's recorded attendance was 80 attendees (at start), 76 (in the middle) and 76 (at the end). 37 attendees left feedback.
"The feedback questions are based on a 5 rating scale, with 5 being the highest score. Your average ratings are shown below:
- Session Meets Expectations: 4.22
- Recommend To Colleague: 4.22
- Presentation Skills: 4.49
- Command Of Topic: 4.73
- Description Matches Content: 4.22
- Overall Rating: 4.24"
The slide deck is available for download here. The Word file for the "Role-ing Doughnut Game" is also available. I print the file on Avery labels (10 to a sheet). I measure and cut 8 cards per sheet out of card stock sheets to mount the labels. The poster for the game is also available for download. I order 3' x 4' posters from FedEx Office.
Please share your experiences in the comments and feel free to send any questions our way.
Did you know that according to job board indeed.com, openings for project managers (PMs) with Agile experience have grown more than 2,500% since 2005?
As more companies seek greater value from technology projects by making the switch from waterfall to Agile, it’s imperative that project managers maximize their value, too, by understanding their role in Agile projects and keeping their skills sharp. A recent global survey from PricewaterhouseCoopers (PwC) showed that 34% of PMs now use Agile methods, and a majority of PMs (62%) are certified Agile practitioners.
“Not only have organisations raised the bar in order to stay competitive in the turbulent business environment, but PM standards have also significantly increased … more practitioners are becoming certified in PM with an increased adaptation of Agile PM and EVM.” (PwC)Get Accredited
Earning your credentials as a Project Management Institute Agile Certified Practitioner (PMI-ACP) is a great way to take your skills and versatility to the next level. If you’re preparing to take the PMI-ACP exam, Agile University has got just the training you need to make you ready to test with flying colors.
Come spend a few days in beautiful Boulder, Colorado, to up your game on topics like:
- The Agile Manifesto
- Lean Basics
- Kanban Design and Value Stream Mapping
- Communication and Information
- Planning, Estimating and Adjustment Practices
- Iterative Risk Management
- Facilitation Techniques and Conflict Resolution
If you want to acquire a thorough understanding of Agile / Lean principles and practices, invest in high-quality professional training, and pass the PMI-ACP exam on the first try, this is the course for you.Sign On Up
Join us November 4-5, 2014. Find out more and register, here.
Can’t make this one? Check our course calendar to see upcoming dates for this and other great classes!Rally Software
Welcome to our August newsletter. Do you also have a dislike for time tracking? Joanne Perold does, and she explains why in this month’s blog post….more. Kanban Training We still have spaces available on our upcoming Kanban Foundation and Advanced courses. Scrum Sense will once again be teaming up with LKU-accredited Kanban Trainer, Dr. Klaus […]
The post News update 2014/08 – 5 Reasons to Kill Time Sheets appeared first on ScrumSense.com.
Traditionell fragen Projektmanager ihre Kollegen: “Wie lange dauert es, das zu entwickeln?“ Sie wollen Kosten berechnen, die Länge des Projekts kalkulieren und möglichst früh wissen, wie viele Ressourcen das Projekt braucht.
Diese Fragen deuten immer in die gleiche Richtung: Die Projektmanager wollen die Unsicherheit aus dem Projekt nehmen. Unsicherheiten gibt es in Projekten genug: Haben die Projektmitarbeiter genügend Ahnung? Bekommt man die Technologie in den Griff? Hat man am Ende für das gesamte Projekt genügend Budget? Findet man die richtigen Features für das Produkt? Wird der Kunde es haben wollen? Werden die Kollegen die geeigneten Lösungen schnell genug finden … und, und, und. Kurz, es wird versucht die Zukunft vorherzusagen und gleichzeitig weiß man ganz genau, dass das gar nicht geht. Denn jeden beschleicht das Gefühl, dass man bei einem Projekt ja etwas Neues macht – also etwas, das es vorher noch nicht gegeben hat, etwas, das noch nie gemacht wurde. Alle diese Fragen können also gar nicht beantwortet werden. Mit diesen Fragen bin ich immer in die Diskussion eingestiegen und habe mich dabei gewundert, wie man als Projektmanager überhaupt annehmen kann, diese Fragen zu Anfang eines Projekts klären zu können. Dann fragte mich letztens ein Zuhörer bei einem meiner Vorträge: „Ist es denn so? Ist es nicht vielmehr so, dass die meisten Projekte sehr wohl von Leuten gemacht werden, die genau das Gleiche schon einmal gemacht haben? Daher kann man doch sehr genau die Aufwände schätzen.” In diesen Fällen wisse man doch genau, wie lange etwas dauere.
Diesem Argument lässt sich nicht viel entgegensetzen, oder? Denn es ist korrekt: Wenn man mehr oder weniger immer das Gleiche tut, kann man auch Vorhersagen treffen. Auf diesem Prinzip basieren auch alle Ansätze der Schätzverfahren in Scrum-Teams. Wenn man zu irgendeinem Zeitpunkt genug Daten darüber hat, wie lange etwas dauert, dann lassen sich sehr wohl die Aufwände schätzen. Aber Moment: In diesem Fall befindet sich ein solches Team doch gar nicht mehr in einem Projektmodus. In diesem Moment, in dem es wiederkehrende Aufgaben vollbringt, ist es wieder in einem Support-, Maintenance- oder Bug-Fixing-Modus. Aber genau dann sollte man doch sofort vom Projektmanagement hin zu einem klassischen Verfahren der Prozesssteuerung und des Workflowmanagements zurückgehen und wo landet man da? Genau – beim Lean Management des Toyota Production Systems. Dann ist man besser damit beraten sich anzusehen, wie man in Call Centern, in Produktionsbetrieben, in der Logistik oder in Einkaufszentren arbeitet. Dort sollten Logistiker den Ton angeben: Denn Workflowmanagement wird seit 40 Jahren nach dem Pull-Verfahren und dem One-Piece-Flow-Verfahren optimal gesteuert. Es hat lange gedauert, bis sich dieses Wissen durchgesetzt hat, aber es war am Ende erfolgreich. Viele Manager, die Sales-Zahlen vorgeben, Absatzzahlen erfinden und Produktionsziele vorgeben wollen, wollten lange nicht wahrhaben: Der Empfänger des Produkts, meist der Kunde, bestimmt durch sein Kaufverhalten, wie viel ein Unternehmen liefern sollte, und nicht die Annahmen darüber, wie viel der Kunde möglicherweise kaufen wird. Das hat der Handel in den letzten 10 Jahren gelernt und man sieht es jeden Tag an der Kasse der Discounter, wie dieses Prinzip funktioniert.
Dieses Denken hat auch in die Software-Entwicklung Einzug gehalten. Die massive Hinwendung vieler Software-Entwicklungsabteilungen hin zu Kanban – die heute sogar in Tools wie JIRAs Ansatz zur Workflowsteuerung gipfeln – lässt sich so erklären, und sie ist folgerichtig. Wo nichts Neues entwickelt, wo keine Projekte gemacht und einfach das immer Gleiche immer wieder neu angepinselt und noch einmal verkauft wird, da gilt es tatsächlich nichts anders als effizientes Workflowmanagement zu machen. Support-Aufgaben hier, ein Bugfix da.
Es gibt Untersuchungen und IT-Leiter, die behaupten, 70% dessen, was entwickelt werde, wäre nunmal Maintenance. Aus meiner Beobachtung stimmt das. Es ist so – aber wieso? Ist das eine Ursache oder ein Symptom? Ich glaube, dass ist das Symptom. Wenn Software-Entwicklung so durchgeführt wird, wie in vielen Unternehmen heute noch immer und am Ende zu gigantischen Bergen technischer Schulden führt, ja dann schreibt man relativ schnell keine neuen Features, sondern ist ständig damit beschäftigt, das Alte anzumalen oder kleine, völlig unbedeutende Veränderungen vorzunehmen. Die wunderbare Präsentation von Salesforce.com zeigt sehr eindrucksvoll, wie das auch einem Internet-Startup wie Salesforces.com sehr schnell passiert ist.
Aber zurück zum Schätzen. In diesen Umfeldern ist es zwar prinzipiell möglich, Aufwände sogar relativ gut und valide zu schätzen, denn man hat ja eh immer das Gleiche zu tun. Aber es ist völlig unnötig, wie uns die Logistikindustrie gezeigt hat. In diesen Umfeldern hat sich etwas anderes durchgesetzt: Die sogenannte Flusssteuerung, die mit Hilfe statistischer Verfahren die Durchflussgeschwindigkeit und die Höhe der Inputschlange bestimmt, und basierend auf diesen Aussagen die Lieferzeiten sehr korrekt ermitteln kann.
Man braucht also gar nicht mehr zu schätzen, sondern man weiß, wann etwas geliefert wird. Diese Ideen hat Kanban für die Software-Entwicklung populär gemacht – es wurden Serviceklassen eingeführt und nun ist man sehr gut darin, mit diesen Verfahren und WIP-Limits die Auslastung von Teams zu steuern. Jedes Schätzen ist hier Zeitvergeudung und vollkommen unnötig. Erklärt man diesen Umstand, schauen mich Projektmanager oft ungläubig an. Die Prinzipien sind zwar einfach, doch leider liegen diese Erkenntnisse quer zu dem, was der gesunde Menschenverstand sagt und vollkommen quer zu dem, was in vielen Unternehmen zum Thema Auslastung, Workflowmanagement etc. gelehrt wird. Es hat 20 Jahre gedauert, bis in der Automobilindustrie die Ideen von Toyota wirklich angekommen sind.
Wenn also Schätzen in diesen Umfeldern nicht mehr notwendig ist, wie ist das dann bei echten Projekten? Also in einem Kontext, in dem etwas versucht wird, das noch nie zuvor versucht worden ist? Ich habe das große Glück, in den letzten beiden Jahren mit Kunden arbeiten zu dürfen, die solche Projekte durchführen. Dort werden tatsächlich Dinge getan, erforscht, erprobt, ausgetüftelt – also Produkte gebaut, die noch nie zuvor ein Mensch gesehen hat. Das ist ein bisschen so wie der erste Mondflug. Man weiß einfach nicht ob es geht. Die einzige Chance, in diesen Projekten zu Ergebnissen zu kommen, ist die Welt zu gestalten. Man erfindet einfach das, was man braucht. Seien es die Entwicklungsmethoden, die Tools oder auch die notwendigen Produktideen. Allerdings ergibt sich aus diesem Vorgehen eine prinzipielles und unlösbares Faktum. Nun kann man einfach nicht mehr voraussagen, wann man fertig ist. Sicher, man kann sich etwas vornehmen, auf ein Ziel hinarbeiten. Doch etwas zu versprechen wäre illusorisch.
Findige Designer haben für Dinge, die nicht zu komplex sind, eine relativ simple Methode gefunden, wie man dennoch Fortschritte dokumentieren kann und wie man sich zumindest auf etwas festlegen kann: Man gibt einen Zeitrahmen vor. Diese zeitliche Grenze erzeugt den notwendigen Druck, zumindest immer auf ein Ziel hinarbeiten zu müssen, sich also nicht selbst zu belügen und einfach ergebnislos vor sich hinzuarbeiten. Zeitliche Grenzen erzeugen den Fokus, man probiert nicht alles aus, sondern liefert mal den erstmöglichen Fortschritt, das erstmögliche Ergebnis. Kann man diesen Zeitrahmen sinnvoll strukturieren? Sicher! Es gibt Techniken wie Design Thinking oder Scrum, die Teams dabei helfen, genau diesen Zeitrahmen zumindest insofern zu strukturieren, dass das Finden von Ergebnissen wahrscheinlicher – nicht aber sicher – wird.
Doch jetzt das Paradoxon: Diese Methoden sind bekannt. Sie sind sogar so erfolgreich, dass die erfolgreichsten Firmen des letzten Jahrzehnts freiwillig erzählen, dass sie darauf setzen. Sie sind sogar in den Firmen bekannt, die bis dato ganz anders gearbeitet haben – dennoch wird stillschweigend noch immer vorausgesetzt, dass man wissen muss, wann zu welchen Kosten und mit welchem Ergebnis auf jeden Fall das geliefert werden soll, was man heute noch gar nicht kennt. Es wird also versucht, diese neuen Methoden in einem Kontext zu leben, der zugegeben hat, dass die Aufgabe unlösbar ist. Deshalb nimmt man die neuen Methoden und gleichzeitig verdrängt man die Tatsache, dass die Aufgabe unlösbar ist.
Aufwände zu schätzen ist in diesen Umfeldern schlicht unmöglich. Das ist jedem klar, und doch wird es immer wieder gefordert. Warum? Der Trugschluss herrscht, dass man mit Hilfe des Schätzens eines bekämpfen könnte: Die Angst, in irgendeiner Weise zu versagen. Es geht also anders ausgedrückt darum, das Risiko zu verringern. Als könne man durch das Schätzen gewährleisten, dass es zu keinem Verlust kommen könnte.
Doch Schätzen ist aus mindestens diesen vier Gründen ungeeignet, das Risiko zu minimieren:
- Aufwandsschätzungen werden zumeist optimistisch abgegeben. Damit wird das Risiko erhöht.
- Aufwände werden als Kostenfaktor gesehen. Damit ist eine hohe Schätzung zwar vielleicht ein Maß für Risiko, aber wirtschaftliche Interessen konterkarieren dieses Thema sofort.
- Wir wissen aus den Arbeiten von Eliyahu Goldratt, Autor von „The Goal“, dem einflussreichsten Buch zur Theory of Constraints, dass im Falle dessen, dass Aufwandsschätzungen zu groß waren, dennoch diese Aufwände aufgebraucht werden. Damit erhöht sich das Risiko, die Puffer des Projekts zu sprengen und wenn dann wirklich eine Schätzung zu gering war, bricht man die zeitlichen Grenzen. Das Projekt wird also riskanter.
- Aufwandsschätzungen sind abhängig von dem, der sie durchführt. Damit erhält man kein objektives Maß für das Risiko.
All das ist hinreichend bekannt. Dennoch erzeugen Aufwandsschätzungen und die sich daran ausrichtende Planung immer wieder die Illusion, das Risiko wäre gebannt. Was durch das Schätzen von Aufwänden also in Wahrheit geschieht: Das Risiko wird nicht eingeschätzt und bewertet, sondern es wird verdrängt und ignoriert. Wir haben geschätzt und gebannt.
Wie wäre es, wenn wir das Risiko benennen würden, ihm ins Gesicht schauen und es angreifbar machen? Wie wäre es, wenn wir von Anfang an sagen würden: Wir haben hier die besten Kollegen zusammengerufen, die wir haben. Wir lassen Sie das Vorhaben mit ungewissem Ausgang wagen. Wir wissen, dass wir nicht wissen können, wann wir fertig sein werden, doch wir nehmen uns Etappen vor, und wir überprüfen immer wieder, was es braucht, um das Ziel zu erreichen. Was wäre, wenn wir offen darüber sprechen würden, dass wir nicht wissen, ob die Technologie die richtige ist, und deshalb davon ausgehen, dass wir bei neuen Erkenntnissen die Richtung noch einmal wechseln können. Was wäre, wenn wir das Risiko dadurch minimieren, dass wir immer einen kleinen Schritt machen und überprüfen, ob wir auf Kurs sind?
Auch dann wäre es nicht nötig zu schätzen. Man schaut einfach, wie viel man ausgegeben kann und wohin man kommen muss, damit man die nächste Investition rechtfertigen kann. Venture Capitalists gehen so vor – und nicht nur diese. Jeder nutzt genau diese Strategie in seinem eigenen privaten Bereich. Man schaut, was man an Ressourcen hat und dann fängt man an. Ist das ideal? Nein, aber der einzige Ausweg für alle, die innovative Produkte auf den Markt bringen wollen.
Für alle, die sich der Unvorhersagbarkeit stellen wollen, habe ich ein Buch geschrieben: Wie schätzt man in agilen Projekten – oder warum Scrum-Projekte erfolgreicher sind.
Today we released a great new update for quickly viewing an item’s detail and history. We developed a modal for the item detail view. Click on an item’s title and a child window opens up with detailed information for that particular item. You can review, comment and add attachments to tickets without losing your place on the main page. Losing context while reviewing items is a piece of feedback we’ve heard often.
This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.
I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.
How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?
Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?
There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.
SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.
SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.
So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.
I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.
All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:
- Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
- Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
- There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
- Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
- 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.
In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.
The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?
I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.
“Pirates are bold not safe” — These guys are doing something good
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
You can get the Weekend Edition delivered directly to you via email by signing up here.
Scrum: a … http://t.co/Qqmr79Mofy
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims… http://t.co/gZVuHo07II
Scrum: a Brea… http://t.co/lGYeIvgakV
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims (Author), Hillary Loui…
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims (Author), Hillary Loui…
Scrum: a Brea… http://t.co/coeL64WC4f
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims… http://t.co/pGwOtGFkwD
Scrum: a … http://t.co/ptnU3LMm15
In part 3 of our look at Project Management with Kanban, we consider project planning using probabilistic forecasting. Kanban originally shocked the Agile community in 2008 as it became known for not using several practices agilists hold dear: no time-boxed iterations; no prioritization; and perhaps most shocking of all, no estimation!!! So how do you plan a project with a method that doesn't use estimates? The answer is that you use historical data or a model of expected capability to build a probabilistic forecast of the project outcome. What follows is a short discussion of one simple and common model for forecasting a project dellivery schedule...
I’m super-excited to introduce Justin Jackson to everybody today. Justin joined us just this week and will be running Sprint.ly’s product marketing. Read on below to learn more about Justin.
Howdy! I’m Justin Jackson and I’m thrilled to be joining the Sprint.ly marketing team.
I’ve spent the past 6 years working in product management and marketing for a SaaS based web application. In 2012 I started using Sprint.ly to manage my team and it radically improved our development process. Every member of our business could see what was being worked on, and what was finished: for the first time ever, everything was transparent. I’ve been a huge believer in Sprint.ly ever since.
When I started my podcast Sprint.ly stepped forward to become my first sponsor. As an active member of the product community, I kept seeing Sprint.ly’s name pop up as a sponsor for other things as well: Rails Rumble, Django Dash, etc… It’s clear that the team is passionate about beautiful products, and the people that make them.
As a product person, Sprint.ly was always one of my favorite products. They seemed to embody everything I liked: amazing design, well though-out user-experience, and commitment to serving all corners of an organization. For me, it’s a dream to be working side-by-side with these amazing folks.
When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.
The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working tested increment of the product… and therefore what defines the basic requirements for a Scrum team.
When you put analysts, designers, developers, and testers into a single workgroup, let them work across skill-set boundaries, self-organize to balance load, and have them collectively produce a working tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.
Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness, you have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.
Why Scrum Breaks?
The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.
When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.
It’s my assertion that these planning dependencies are what results in teams going through the motions of Scrum without realizing value Scrum promises. Last week I did a talk at Agile2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.
That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.
The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.
SAFe and Value Streams
I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise level scale. Scaling Scrum is the topic de jour.
Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean has written since he released Scaling Software Agility, have a ton of respect for his work, and agree with the basic patterns he has introduced.
This conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.
At LeadingAgile, we typically coach an explicit value stream in the middle level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.
It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier, it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.
Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.
SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.
We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.
We believe this concept is methodology independent and will make any methodology you choose better in the long run.
Why SAFe Breaks?
Scrum isn’t trying to break dependencies within the team, it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working tested increment every couple of weeks.
SAFe isn’t trying to break dependencies either within these larger value streams either, it is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work and stabilize throughput, while producing a working tested increment every PI.
There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?
If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.
If SAFe is going to ultimately struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about SAFe’s of SAFe’s or SAFe Product Owner Teams or SAFe Portfolio Solutions Teams?
I suspect we might. I think we might also be seeing evidence of this already.
Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already given how well SAFe is doing in market.
If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon and are people talking about this?
Ken and Jeff Got it Right
Back in 2006 Ken Schwaber put up a slide where he illustrated a team of teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely-coupled teams (and at that time, that was NOT my reality).
A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that ‘teams were never expected to self-organize across class boundaries’. They were implicitly saying that encapsulation was the expectation for a Scrum team to form.
Jeff Sutherland, as we speak over at Scrum.com is talking about Object Oriented Design in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.
I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum now-a-days don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.
When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put in place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago but that is seldom implemented.
I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum,
SAFe Is A Compromise
I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.
That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.
At this point in the evolution of my thinking, I find myself in a place where I don’t believe the Scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.
We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.
Refactoring Your Enterprise
The only real, long term sustainable approach to Scaled Enterprise Agile is to take the long hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.
The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peace harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery, and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.
With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future states starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like that help us get there, while still running our businesses effectively.
If I think about it… that was really what my talk last week was about. The talk is up on the blog, and it was recorded by the conference, but that might take a few weeks to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend ;-)
The post Encapsulating Value Streams and the Object Oriented Enterprise appeared first on LeadingAgile.
Leadership is well defined - that's not the problem - the problem is it has many, many various definitions. Leadership definitions change throughout time. Your grandfather's definition of leadership may vary quite drastically from your's - ask him if you have the opportunity.
A modern classic definition:
Leadership is a process whereby an individual influences a group of individuals to achieve a common goal. -- Peter Northouse
A brief history of Leadership
A working definition of leadership
Is leadership a process
May leadership emerge from a group
Is leadership more than a form of coercion and power
Various Leadership Approaches
Situational, Skills, Style, Trait
Leader-Member Exchange Theory
Transformational Leadership Model
Servant Leadership Model
Authentic Leadership Model
Team Leadership Model
Disclaimer: as this blog is a from of note keeping for me - an extension of my cognitive model of the universe of knowledge - this article and the series of article may be in great flux until complete (or good enough to quit editing).
1) Leadership Theory and Practice - 6th Ed. by Peter Northouse.