Skip to content


Don’t try and do it alone.

Derick Bailey - new ThoughtStream - Wed, 08/13/2014 - 20:51


I don’t know where I would be without my friends and my entrepreneurship group.

Staring at a blank canvas or an empty file that I am supposed to fill with code is terrifying. It’s like looking over the edge of the world, in to the abyss. It can drive me mad at times. The emptiness… the limitless possibilities… where to start? What to do? What’s the most important thing? What are the pieces that absolutely must be there, first? With code, at least, I can typically just start hacking junk together and then later realize where I should have actually started. But when it comes to business and planning … I get lost, quickly.

Yet I’m a quick learner, an intrinsically motivated person and someone that is always moving projects forward toward a goal. It’s what makes me good at consulting, I think. I can walk in to a situation, evaluate the circumstances and create movement in the direction that is needed. But it gets overwhelming, quickly. Doing things on my own, with no accountability other than me and my customers, is really hard some times.

Fortunately, I don’t have to do this alone. I’m never without help, and I can’t imagine ever being without help.

While I may not have a boss telling me what to do, and I don’t have coworkers that I can bounce ideas off all the time, I do have a support network that can help me in the same ways. In my case, I have 3 different “groups” that I can talk with. I have my entrepreneurship group that meets every friday. I have a good friend who also happens to be my current client for contract work, that is doing his own thing in some very different ways. And I have my dad – a man that has been an entrepreneur for longer than I’ve been alive.

I’m never truly alone in any of this. And you shouldn’t be, either.

It’s dangerous to go alone – especially when you don’t know what you’re doing. In anything new, important, difficult, or even just different in your life, find a support group of some kind. Whether it’s coworkers that get together and talk at lunch, a group of people outside work that talk once a week and/or via email, friends that you know and trust, or whoever it might be. Find someone, some group, somewhere that you can be a part of, that will accept you for all your amazing talents and horrifying faults, and that will be there for you when you need help.

I rely on my support network every day. Knowing what my limits are, where I lack discipline and experience – this is part of growing and understanding, becoming a better entrepreneur, developer, or just plain better me.

I don’t know where I would be without Josh, John, Justin and my dad.  I do know that I would not be where I am today without them, or without everyone else that has helped me in my career. All of my coworkers. All of my friends. All of the people that are currently in my life, helping me through this - I can’t imagine how I would be where I am now, without them.

I only hope that I can offer the same kind of support, inspiration and motivation to someone else, one day.

    – Derick

     Related Stories 
Categories: Blogs

Business Capabilities and Microservices

Leading Agile - Mike Cottmeyer - Wed, 08/13/2014 - 17:25

I don’t often use this forum to link out to other websites and authors, but I read a post last night by Martin Fowler and James Lewis that really gets to the heart of this issue around encapsulation, decoupling, and value streams I’ve been talking about lately.

The article does a great job of describing the problem and the end-state solution… it doesn’t say much about how to get there. Even so, I was impressed by the article and I wanted to share it with you guys in case you haven’t seen it.

I think this kind of architecture might be a prerequisite for true agile at scale, take a look:

UPDATE: Here is another interesting post I just discovered on Twitter by Richard Clayton highlighting some of the mistakes they made implementing this approach. Doesn’t invalidate the concept, just some good things to be aware of.

The post Business Capabilities and Microservices appeared first on LeadingAgile.

Categories: Blogs

People Are Not Resources

Johanna Rothman - Wed, 08/13/2014 - 15:06

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!

Go read Management Myth 32: I Can Treat People as Interchangeable Resources.

Categories: Blogs

Success Articles for Work and Life

J.D. Meier's Blog - Wed, 08/13/2014 - 08:01

"Success consists of going from failure to failure without loss of enthusiasm." -- Winston Churchill

I now have more than 300 articles on the topic of Success to help you get your game on in work and life:

Success Articles

That’s a whole lot of success strategies and insights right at your fingertips. (And it includes the genius from a wide variety of sources including  Scott Adams, Tony Robbins, Bruce Lee, Zig Ziglar, and more.)

Success is a hot topic. 

Success has always been a hot topic, but it seems to be growing in popularity.  I suspect it’s because so many people are being tested in so many new ways and competition is fierce.

But What is Success? (I tried to answer that using Zig Ziglar’s frame for success.)

For another perspective, see Success Defined (It includes definitions of success from Stephen Covey and John Maxwell.)

At the end of the day, the most important definition of success, is the one that you apply to you and your life.

People can make or break themselves based on how they define success for their life.

Some people define success as another day above ground, but for others they have a very high, and very strict bar that only a few mere mortals can ever achieve.

That said, everybody is looking for an edge.   And, I think our best edge is always our inner edge.

As my one mentor put it, “the fastest thing you can change in any situation is yourself.”  And as we all know, nature favors the flexible.  Our ability to adapt and respond to our changing environment is the backbone of success.   Otherwise, success is fleeting, and it has a funny way of eluding or evading us.

I picked a few of my favorite articles on success.  These ones are a little different by design.  Here they are:

Scott Adam’s (Dilbert) Success Formula

It’s the Pebble in Your Shoe

The Wolves Within

Personal Leadership Helps Renew You

The Power of Personal Leadership

Tony Robbins on the 7 Traits of Success

The Way of Success

The future is definitely uncertain.  I’m certain of that.   But I’m also certain that life’s better with skill and that the right success strategies under your belt can make or break you in work and life.

And the good news for us is that success leaves clues.

So make like a student and study.

Categories: Blogs

Who should be in (agile) HR?

Scrum 4 You - Wed, 08/13/2014 - 07:41

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!

Related posts:

  1. Organisations need to understand …
  2. 5 minutes on management
  3. Massive Multiplayer Online Games the Digital Business School of the Next Generation

Categories: Blogs

An Existence Proof and The Value of Coaching

Practical Agility - Dave Rooney - Tue, 08/12/2014 - 19:00
I found a tweet I saw this morning rather disconcerting: An embedded #agile coach billing $2500 a day for 221 days can in theory generate this much per yr: $552,500. Q: What does the client get? — Daniel Mezick (@DanielMezick) August 12, 2014 The clear implication is that coaches, like all consultants, follow the mantra, "If you can't be part of the solution, there's plenty of money to be made
Categories: Blogs

Agile Chronicles (Composite Stories) – Agile Artifacts – Ephemeral v. Enduring Value

Leading Agile - Mike Cottmeyer - Tue, 08/12/2014 - 17:22

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.

Categories: Blogs

Meet: Scrum 2.0

Learn more about our Scrum and Agile training sessions on


Feedback from first version incorporated.

More welcome!


Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Agile Bootcamp Talk Posted on Slideshare

Johanna Rothman - Tue, 08/12/2014 - 13:46

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.

Categories: Blogs

If Everybody’s Happy, You’re Doing It Wrong

Agile Tools - Tue, 08/12/2014 - 08:18

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
Categories: Blogs

Hierarchies remove scaling properties in Agile Software projects

Software Development Today - Vasco Duarte - Tue, 08/12/2014 - 06:00

There is a lot of interest in scaling Agile Software Development. And that is a good thing. Software projects of all sizes benefit from what we have learned over the years about Agile Software Development.

Many frameworks have been developed to help us implement Agile at scale. We have: SAFe, DAD, Large-scale Scrum, etc. I am also aware of other models for scaled Agile development in specific industries, and those efforts go beyond what the frameworks above discuss or tackle.

However, scaling as a problem is neither a software nor an Agile topic. Humanity has been scaling its activities for millennia, and very successfully at that. The Pyramids in Egypt, the Panama Canal in central America, the immense railways all over the world, the Airbus A380, etc.

All of these scaling efforts share some commonalities with software and among each other, but they are also very different. I'd like to focus on one particular aspect of scaling that has a huge impact on software development: communication.

The key to scaling software development

We've all heard countless accounts of projects gone wrong because of lack (inadequate, or just plain bad) communication. And typically, these problems grow with the size of the team. Communication is a major challenge in scaling any human endeavor, and especially one - like software - that so heavily depends on successful communication patterns.

In my own work in scaling software development I've focused on communication networks. In fact, I believe that scaling software development is first an exercise in understanding communication networks. Without understanding the existing and necessary communication networks in large projects we will not be able to help those project adapt. In many projects, a different approach is used: hierarchical management with strict (and non-adaptable) communication paths. This approach effectively reduces the adaptability and resilience in software projects.

Scaling software development is first and foremost an exercise in understanding communication networks.

Even if hierarchies can successfully scale projects where communication needs are known in advance (like building a railway network for example), hierarchies are very ineffective at handling adaptive communication needs. Hierarchies slow communication down to a manageable speed (manageable for those at the top), and reduce the amount of information transferred upwards (managers filter what is important - according to their own view).

In a software project those properties of hierarchy-bound communication networks restrict valuable information from reaching stakeholders. As a consequence one can say that hierarchies remove scaling properties from software development. Hierarchical communication networks restrict information reach without concern for those who would benefit from that information because the goal is to "streamline" communication so that it adheres to the hierarchy.

In software development, one must constantly map, develop and re-invent the communication networks to allow for the right information to reach the relevant stakeholders at all times. Hence, the role of project management in scaled agile projects is to curate communication networks: map, intervene, document, and experiment with communication networks by involving the stakeholders.

Scaling agile software development is - in its essential form - a work of developing and evolving communication networks.

A special thank you note to Esko Kilpi and Clay Shirky for the inspiration for this post through their writings on organizational patterns and value networks in organizations.

Picture credit: John Hammink, follow him on twitter

Categories: Blogs

Aggressive Decoupling of Scrum Teams

Leading Agile - Mike Cottmeyer - Tue, 08/12/2014 - 04:09

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…

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…

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.

The post Aggressive Decoupling of Scrum Teams appeared first on LeadingAgile.

Categories: Blogs

R: Grouping by two variables

Mark Needham - Mon, 08/11/2014 - 18:47

In my continued playing around with R and meetup data I wanted to group a data table by two variables – day and event – so I could see the most popular day of the week for meetups and which events we’d held on those days.

I started off with the following data table:

> head(eventsOf2014, 20)
      eventTime                                     rsvps            datetime       day monthYear
16 1.393351e+12                                         Intro to Graphs    38 2014-02-25 18:00:00   Tuesday   02-2014
17 1.403635e+12                                         Intro to Graphs    44 2014-06-24 18:30:00   Tuesday   06-2014
19 1.404844e+12                                         Intro to Graphs    38 2014-07-08 18:30:00   Tuesday   07-2014
28 1.398796e+12                                         Intro to Graphs    45 2014-04-29 18:30:00   Tuesday   04-2014
31 1.395772e+12                                         Intro to Graphs    56 2014-03-25 18:30:00   Tuesday   03-2014
41 1.406054e+12                                         Intro to Graphs    12 2014-07-22 18:30:00   Tuesday   07-2014
49 1.395167e+12                                         Intro to Graphs    45 2014-03-18 18:30:00   Tuesday   03-2014
50 1.401907e+12                                         Intro to Graphs    35 2014-06-04 18:30:00 Wednesday   06-2014
51 1.400006e+12                                         Intro to Graphs    31 2014-05-13 18:30:00   Tuesday   05-2014
54 1.392142e+12                                         Intro to Graphs    35 2014-02-11 18:00:00   Tuesday   02-2014
59 1.400611e+12                                         Intro to Graphs    53 2014-05-20 18:30:00   Tuesday   05-2014
61 1.390932e+12                                         Intro to Graphs    22 2014-01-28 18:00:00   Tuesday   01-2014
70 1.397587e+12                                         Intro to Graphs    47 2014-04-15 18:30:00   Tuesday   04-2014
7  1.402425e+12       Hands On Intro to Cypher - Neo4j's Query Language    38 2014-06-10 18:30:00   Tuesday   06-2014
25 1.397155e+12       Hands On Intro to Cypher - Neo4j's Query Language    28 2014-04-10 18:30:00  Thursday   04-2014
44 1.404326e+12       Hands On Intro to Cypher - Neo4j's Query Language    43 2014-07-02 18:30:00 Wednesday   07-2014
46 1.398364e+12       Hands On Intro to Cypher - Neo4j's Query Language    30 2014-04-24 18:30:00  Thursday   04-2014
65 1.400783e+12       Hands On Intro to Cypher - Neo4j's Query Language    26 2014-05-22 18:30:00  Thursday   05-2014
5  1.403203e+12 Hands on build your first Neo4j app for Java developers    34 2014-06-19 18:30:00  Thursday   06-2014
34 1.399574e+12 Hands on build your first Neo4j app for Java developers    28 2014-05-08 18:30:00  Thursday   05-2014

I was able to work out the average number of RSVPs per day with the following code using plyr:

> ddply(eventsOf2014, .(day=format(datetime, "%A")), summarise, 
        rsvpsPerEvent = rsvps / count)
        day count rsvps rsvpsPerEvent
1  Thursday     5   146      29.20000
2   Tuesday    13   504      38.76923
3 Wednesday     2    78      39.00000

The next step was to show the names of events that happened on those days next to the row for that day. To do this we can make use of the paste function like so:

> ddply(eventsOf2014, .(day=format(datetime, "%A")), summarise, 
        events = paste(unique(, collapse = ","),
        rsvpsPerEvent = rsvps / count)
        day                                                                                                    events count rsvps rsvpsPerEvent
1  Thursday Hands On Intro to Cypher - Neo4j's Query Language,Hands on build your first Neo4j app for Java developers     5   146      29.20000
2   Tuesday                                         Intro to Graphs,Hands On Intro to Cypher - Neo4j's Query Language    13   504      38.76923
3 Wednesday                                         Intro to Graphs,Hands On Intro to Cypher - Neo4j's Query Language     2    78      39.00000

If we wanted to drill down further and see the number of RSVPs per day per event type then we could instead group by the day and event name:

> ddply(eventsOf2014, .(day=format(datetime, "%A"),, summarise, 
        rsvpsPerEvent = rsvps / count)
        day                                     count rsvps rsvpsPerEvent
1  Thursday Hands on build your first Neo4j app for Java developers     2    62      31.00000
2  Thursday       Hands On Intro to Cypher - Neo4j's Query Language     3    84      28.00000
3   Tuesday       Hands On Intro to Cypher - Neo4j's Query Language     1    38      38.00000
4   Tuesday                                         Intro to Graphs    12   466      38.83333
5 Wednesday       Hands On Intro to Cypher - Neo4j's Query Language     1    43      43.00000
6 Wednesday                                         Intro to Graphs     1    35      35.00000

There are too few data points for some of those to make any decisions but as we gather more data hopefully we’ll see if there’s a trend for people to come to events on certain days or not.

Categories: Blogs

News update 2014/08 – 5 Reasons to Kill Time Sheets - Peter Hundermark - Mon, 08/11/2014 - 08:45

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

Categories: Blogs

Sag mir, wie du schätzt und ich sage dir, wer du bist

Scrum 4 You - Mon, 08/11/2014 - 07:07

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 zeigt sehr eindrucksvoll, wie das auch einem Internet-Startup wie 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.
  2. 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.
  3. 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.

Related posts:

  1. Estimation! Schätzen von Story Points
  2. Agile Estimation | Grundlagen
  3. Dr. Scrum – Antwortet :)

Categories: Blogs

Designing a job crafting experience

Alastair Simpson created a Mentor Canvas intended for mentoring UX designer.

I generally like it because it provides a reasonable structure in a collaborative, canvas style.

However, to make it more appealing to me, I'd like to adjust it to generalise to a non-UX designer perspective and also to reflect some slightly different assumptions of what I consider important for developing oneself and others.  Specifically, I prefer a job crafting approach.

I've created a template on Google Drive:

Categories: Blogs

Agile 2014 - Final Thoughts

A number of themes surfaced during Agile2014. One of the big themes was scaling agile. There were a number of presentations on the SAFe model, Discipled Agile (DAD) and the new framework by Jeff Sutherland. There was also a lot of discussion on how Spotify scaled agile (be sure to download the paper).  
I appreciated the opportunity to hear about DAD from the creators, Scott Ambler and Mark Lines. Mark gave a presentation on how this framework was implemented at Panera Bread. The next day, Scott provided more details on their framework. 
One common opinion professed by many of the presenters was that there is no one size fits all with agile. There are no best practices. Everything has to be taken in the context of the organization where agile is being implemented. Experiment. Fail fast. Try again. Don’t copy what Spotify did just because it was so effective for them. You can start with a framework, but don't just follow a framework.
The topic of delivering value came up as well. Pat Reed/Walt Wyckoff from iHoriz did a good presentation on a value based framework for portfolio management. Pat stated that even now, 60-90% of features don’t deliver the value that was desired. Another presenter said we shouldn’t focus on shippable code but consumable code. It doesn't matter if it ships, it matters if it gets used. Only then is it bringing value.
There were other topics getting attention, including DevOps and #NoEstimates. The Coaches Clinic and Open Jam added to the value of the conference as well. I'm also sure there were topics I missed. With well over 200 presentations, it's hard to catch everything.
I think a conference like this is a great way to spark some new ideas and maybe help you get out of a rut with your day-to-day routine. Keep in mind that agile is all about inspect and adapt. If you successfully implement agile but then don't try to improve from their, you're doing agile but not being agile. 
If you missed the conference and want to get a flavor for it, here are some resources:
Big Visible interviews with many of the conference speakers
Agile Alliance posting of keynote presentations from the conference
Projects at Work interviews with conference attendees
Categories: Blogs

The Agile Reader – Weekend Edition: 08/09/2014 - Kane Mar - Sat, 08/09/2014 - 11:10

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.

  • Accenture #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) #job in (#Chennai)
  • Read > #Kindle #5190 #1: Scrum: a Breathtakingly Brief and Agile Introduction

    Scrum: a …

  • Delivery Manager – Agile Green software Hopper Scrum Offshore – (New York) #NYC #NewYork #News
  • Accenture #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai)
  • Accenture is looking for a Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai) #job
  • Medical Mutual: Web Business Analyst – Agile Scrum Master 14-267 (#Strongsville, OH) #IT #Job #Jobs
  • Read Book : #Kindle #7345 #1: Scrum: a Breathtakingly Brief and Agile Introduction


  • RT @camilolope: minha apresentação ontem no #TDC2014 #scrum #agile @TheDevConf #fb
  • RT @yochum: Encapsulating Value Streams and the Object Oriented Enterprise #agile #scrum
  • NET Development Lead – Web Apps – C# MVC – Agile Scrum
  • Check this out: The FREE SCRUM EBOOK as sold on Amazon. #Scrum #Agile inspired by #Ken Schwaber
  • Delivery Manager – Scrum Offshore Green Agile Hopper – (New York) #NYC #NewYork #News
  • Read This Book : #Kindle

    Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims…

  • READ #1: Scrum: a Breathtakingly Brief and Agile Introduction KINDLE #262

    Scrum: a Brea…

  • READ THIS BOOK Kindle #44

    Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims (Author), Hillary Loui…

  • Homework help: eXtreme Programming (XP) and Scrum are two aspects of agile development. #Homework help
  • Books & Deals >> #Kindle #9033 #5: Scrum: a Breathtakingly Brief and Agile Introduction
  • #IT #Job in #Strongsville, OH: Agile Scrum Master – Project Manager 14-266 at Medical Mutual #Jobs
  • New Books >> #Kindle #5666 #5: Scrum: a Breathtakingly Brief and Agile Introduction


  • Read This Book : #Kindle #6655 #1: Scrum: a Breathtakingly Brief and Agile Introduction
  • Agile by McKnight, Scrum by Day is out! Stories via @marcomilone @CanadaAgileJobs
  • Great article about courage by @TheStrayMuse #Agile #scrum
  • READ THIS BOOK Kindle #44

    Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims (Author), Hillary Loui…

  • READ #1: Scrum: a Breathtakingly Brief and Agile Introduction KINDLE #262

    Scrum: a Brea…

  • Read This Book : #Kindle

    Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims…

  • Read Book : #Kindle #213 #1: Scrum: a Breathtakingly Brief and Agile Introduction


  • Scrum Framework Explained: #scrum #agile
  • RT @yochum: Project Management with Kanban (Part 3) – Forecasting #agile #scrum
  • READ BOOK > # Kindle #61 #1: Scrum: a Breathtakingly Brief and Agile Introduction


  • Now hiring for Scrum Master/Agile Coach in London, United Kingdom #job
  • Senior Product Owner: GenoLogics (Victoria): “This is an Agile Scrum Product Owner position, reporting… #bc #jobs
  • RT @AgileLeanEu: Want to win an #ALE14 ticket? Find out how! @FutureProcessin #agile #scrum #europe #omgkrk http://t…
  • Read Book : #Kindle #5142 #1: Scrum: a Breathtakingly Brief and Agile Introduction


  • My FREE SCRUM EBOOK as sold on Amazon is available here. #Scrum #Agile inspired by #Ken Schwaber
  • Read > #Kindle #5190 #6: Scrum: a Breathtakingly Brief and Agile Introduction

    Scrum: a …

  • #Software … – #Agile #Backend #Development #Engineer #Scrum #Talented #Testing
  • Understand the concepts of #Agile and #Scrum philosophies to Change and Project Managers #softwaredevelopment
  • Agile & Scrum Training In Frankfurt, Germany On 29th Aug 2014: #HOUSTON #TX #Seminars #events
  • Read Book : #Kindle #5142 #1: Scrum: a Breathtakingly Brief and Agile Introduction


  • RT @EventsNearHere: Agile & Scrum Training In Frankfurt, Germany On 29th Aug 2014: #HOUSTON #TX #Seminars #events
  • Read #Book : #Kindle #201 #1: Scrum: a Breathtakingly Brief and Agile Introduction


  • Categories: Blogs

    Lean Agile Scotland 2014

    AvailAgility - Karl Scotland - Sat, 08/09/2014 - 10:00

    I’m going to be at Lean Agile Scotland again next month. I had to miss it last year, but I really can’t decline the opportunity to be at a conference named after me! I’m running a workshop on “Building a Learning Organisation the Kanban Way”. Here’s the abstract:

    In a world of Big Bang Disruption, the need for learning organisations is greater than ever. Businesses need to develop people to be able to continuously solve problems as well as implement solutions. This workshop will introduce a canvas that can be used to apply Kanban Thinking. Participants will work through the canvas, learning how the different parts can help towards enabling continuous improvement.

    I’m told there are still a few tickets left. And I have a discount code which will get you 10% off the ticket price. Just let me know if thats of any use and I can send you the details. I hope to see you there!

    Categories: Blogs

    Are You Doing Agile Results?

    J.D. Meier's Blog - Fri, 08/08/2014 - 18:32

    If you already use Agile Results as your personal results system, you have a big advantage.


    Because most people are running around, scrambling through a laundry list of too many things to do, a lack of clarity around what the end result or outcomes should be, and a lack of clarity around what the high-value things to focus on are.  They are using their worst energy for their most important things.  They are spending too much time on the things that don’t matter and not enough time on the things that do.   They are feeling at their worst, when they need to feel at their best, and they are struggling to keep up with the pace of change.

    I created Agile Results to deal with the chaos in work and life, as a way to rise above the noise, and to easily leverage the most powerful habits and practices for getting better results in work and life.

    Agile Results, in a nutshell, is a simple system for mastering productivity and time management, while at the same time, achieving more impact, realizing your potential, and feeling more fulfillment.

    I wrote about the system in the book Getting Results the Agile Way.  It’s been a best seller in time management.

    How Does Agile Results Work?

    Agile Results works by combining proven practices for productivity, time management, psychology, project management, and some of the best lessons learned on high-performance.   And it’s been tested for more than a decade under extreme scenarios and a variety of conditions from individuals to large teams.

    Work-Life balance is baked into the system, but more importantly Agile Results helps you live your values wherever you are, play to your strengths, and rapidly learn how to improve your results in an situation.  When you spend more time in your values, you naturally tap into your skills and abilities that help bring out your best.

    The simplest way to think of Agile Results is that it helps you direct your attention and apply your effort on the things that count.  By spending more time on high-value activities and by getting intentional about your outcomes, you dramatically improve your ability to get better results.

    But none of that matters if you aren’t using Agile Results.

    How Can You Start Using Agile Results?

    Start simple.

    Simply ask yourself, “What are the 3 wins, results, or outcomes that I want for today?.”   Consider the demands you have on your plate, the time and energy you’ve got, and the opportunities you have for today, and write those 3 things down.

    That’s it.   You’re doing Agile Results.

    Of course, there’s more, but that’s the single most important thing you can do to immediately gain clarity, regain your focus, and spend your time and energy on the most valuable things.

    Now, let’s assume this is the only post you ever read on Agile Results.   Let’s take a fast walkthrough of how you could use the system on a regular basis to radically and rapidly improve your results on an ongoing basis.

    How I Do Agile Results? …

    Here’s a summary of how I do Agile Results.

    I create a new monthly list at the start of each month that lists out all the things that I think I need to do, and I bubble up 3 of my best things I could achieve or must get done to the top.   I look at it at the start of the week, and any time I’m worried if I’m missing something.  This entire process takes me anywhere from 10-20 minutes a month.

    I create a weekly list at the start of the week, and I look at it at the start of each day, as input to my 3 target wins or outcomes for the day, and any time I’m worried if I’m missing anything.   This tends to take me 5-10 minutes at the start of the week.

    I barely have to ever look at my lists – it’s the act of writing things down that gives me quick focus on what’s important.   I’m careful not to put a bunch of minutia in my lists, because then I’d train my brain to stop focusing on what’s important, and I would become forgetful and distracted.  Instead, it’s simple scaffolding.

    Each day, I write a simple list of what’s on my mind and things I think I need to achieve.   Next, I step back and ask myself, “What are the 3 things I want to accomplish today?”, and I write those down.   (This tends to take me 5 minutes or less.  When I first started it took me about 10.)

    Each Friday, I take the time to think through three things going well and three things to improve.   I take what I learn as input into how I can simplify work and life, and how I can improve my results with less effort and more effectiveness.   This takes me 10-20 minutes each Friday.

    How Can You Adopt Agile Results?

    Use it to plan your day, your week, and your month.

    Here is a simple recipe for adopting Agile Results and using it to get better results in work and life:

    1. Add a recurring appointment on your calendar for Monday mornings.  Call it Monday Vision.   Add this text to the body of the reminder: “What are your 3 wins for this week?”
    2. Add a recurring appointment on your calendar to pop up every day in the morning.  Call it Daily Wins.  Add this text to the body of the reminder: “What are your 3 wins for today?”
    3. Add a recurring appointment on your calendar to pop up every Friday mid-morning.  Call it Friday Reflection.  Add this text to the body of your reminder:  What are 3 things going well?  What are 3 things to improve?”
    4. On the last day of the month, make a full list of everything you care about for the next month.   Alphabetize the list.  Identify the 3 most important things that you want to accomplish for the month, and put those at the top of the list.   Call this list  Monthly Results for Month XYZ.  (Note – Alphabetizing your list helps you name your list better and sort your list better.  It’s hard to refer to something important you have to do if you don’t even have a name for it.  If naming the things on your list and sorting them is too much to do, you don’t need to.  It’s just an additional tip that helps you get even more effective and more efficient.)
    5. On Monday of each week, when you wake up, make a full list of everything you care about accomplishing for the week.  Alphabetize the list.  Identify the 3 most important things you want to accomplish and add that to the top of the list.  (Again, if you don’t want to alphabetize then don’t.)
    6. On Wednesdays, in the morning, review the three things you want to accomplish for the week to see if anything matters that you should have spent time on or completed by now.  Readjust your priorities and focus as appropriate.  Remember that the purpose of having the list of your most important outcomes for the week isn’t to get good at predicting what’s important.  It’s to help you focus and to help you make better decisions about what to spend time on throughout the week.  If something better comes along, then at least you can make a conscious decision to trade up and focus on that.  Keep trading up.   And when you look back on Friday, you’ll know whether you are getting better at trading up or if you are just getting randomize or focusing on the short-term but hurting the long term.
    7. On Fridays,  in the morning, do your Friday Reflection.  As part of the exercise, check against your weekly outcomes and your monthly outcomes that you want to accomplish.  If you aren’t effective for the week, don’t ask “why not,” ask “how to.”   Ask how can you bite off better things and how can you make better choices throughout the week.  Just focus on little behavior changes, and this will add up over time.  You’ll get better and better as you go, as long as you keep learning and changing your approach.   That’s the Agile Way.

    There are lots of success stories by other people who have used Agile Results.   Everybody from presidents of companies to people in the trenches, to doctors and teachers, to teams and leaders, as well as single parents and social workers.

    But none of that matters if it’s not your story.

    Work on your success story and just start getting better results, right here, right now.

    What are the three most important things you really want to accomplish or achieve today?

    Categories: Blogs