Skip to content

Feed aggregator

Blog Series: TDD and Process, Part 4

NetObjectives - Mon, 04/17/2017 - 14:16
Part 4: Redundancy In part 3, we examined how the same specification can be bound to the production system in different ways, producing executable tests that have various levels of granularity and speed, by creating different bindings for different purposes.  We started with the “full stack” binding: Next, we created a different binding that avoided accessing the database at all by mocking...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Targetprocess v.3.11.1: add/edit permissions separated, expand all in List views

TargetProcess - Edge of Chaos Blog - Mon, 04/17/2017 - 08:59
'Expand All' in List views

You can now expand and collapse all of the first and second List hierarchy levels. If you hold Ctrl (Cmd) and click '>' then cards from both levels will be expanded. This works for the first two hierarchy levels of a List view and doesn't affect the third level of cards in terms of List setup.

Permissions to create users through the API for non-admins

Previously, only admin users could post Rest API requests to create and delete users. Now, non-admin users with 'add user' / 'delete user' permissions can create/delete users via API calls.

Add and edit permissions separated for user roles

Starting with v.3.11.1, user roles have separate permissions for adding and editing.


Request email notifications settings updated with "Requesters" check-box

You can set up a 'Request' workflow so that requesters get email notifications every time a specific event event occurs.


Visual Encoding improvements

It’s possible to create a predefined set of global Visual Encoding rules that can be applied to all views and all users. To do this, simply select the corresponding checkbox in the Visual Encoding tab and add the global rules that you want applied to every view in the system:


This setting can only be managed by Administrators; other users can see it in read-only mode.

Fixed Bugs
  • Visual studio add-in supports VS2015 now
  • It wasn't possible to delete a test plan if it had test cases that were run already
  • Fixed occasional improper results when searching by ID in a Relations tab
  • Fixed Project-Team assigments for Observer users according to their permissions.
  • Obsolete Tp.v2 option 'Show in lists/enable for filtering' removed from custom fields setup
  • Fixed User Story progress calculation when converting a Task with time records into a User Story
Categories: Companies

SAFe 4.0 Distilled: A Practical Guide for Implementing the World’s Leading Framework for Enterprise Agility

Agile Product Owner - Mon, 04/17/2017 - 03:01

The SAFe knowledge base on this website is an invaluable resource for people who build software and systems, however, navigating the guidance can be daunting for the uninitiated. SAFe is a robust framework supported by hundreds of web pages. Where do you start? In what order should you read the articles? What information is really important to you and when?

We get it. There’s a Wikipedia aspect to the SAFe body of knowledge that takes time to parse. Last year’s publication, the SAFe 4.0 Reference Guide is a handy companion, but it’s basically a printed version of the website. It doesn’t really tell a story and that’s why we wrote the new book SAFe 4.0 Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering.

This is the first book that guides you through SAFe so you can learn how each component of the Framework works together to enable the kind of business results you see in our case studies. It will help you understand how to think about the Framework, how to plan, how to train and mobilize a Lean-Agile workforce, and what to expect as you roll out SAFe in your enterprise. The “Implementing SAFe” section alone is worth the price of the book, as it will help you avoid many of those ‘I wish I’d known that earlier’ moments.

“’SAFe 4.0 Distilled’ is the book we’ve all been waiting for. It breaks down the complexity of the Framework into easily digestible explanations and actionable guidance. A must-have resource for beginners as well as seasoned practitioners.”
Lee Cunningham, Senior Director, Enterprise Agile Strategy at VersionOne, Inc.

In some sections, such as SAFe principles, values, leadership, and implementation, we significantly enhanced the guidance to enable managers and leaders to ‘know what it is they must do’ to lead a Lean-Agile transformation, and create a work environment that truly fosters innovation and employee engagement.

This book is an ideal supplement to formal training and certification, and recommended for every SAFe practitioner. Regardless of whether you’re just starting out, or are engaged in a mature implementation, we have no doubt you’ll find something valuable that will enhance your experience with SAFe.

Published by Addison-Wesley Professional, SAFe Distilled is available in paperback, eBook, and Kindle formats at most major retailers. Learn more about SAFe Distilled, and make sure to use the code, SAFEBOOKS, to save 35 percent off the list price when you purchase from

We hope this new book enriches your SAFe learning journey, and helps make your workplace truly engaging, innovative, more productive, and simply, more fun.

Be SAFe!
—Richard Knaster and Dean Leffingwell, coauthors, SAFe 4.0 Distilled

Categories: Blogs

Article 12 in SAFe Implementation Roadmap series: Sustain and Improve

Agile Product Owner - Mon, 04/17/2017 - 01:51
Click to enlarge

If you’ve been reading the SAFe Implementation Roadmap article series and have made it to this stage, congratulations! When leaders are diligent in following these critical moves, and are making the appropriate course corrections along the way, the results for the organization should look like this:

  • The new way of working is becoming a part of the culture all the way from team, to program, to value stream, to portfolio
  • Substantial business benefits are accumulating every day
  • Improvements in quality, productivity, time to market, and employee engagement are meeting or exceeding expectations

You should now being seeing results like those in the case studies. These are great accomplishments, but how do you sustain them over the long term? Culture change can lose momentum as the ‘new car smell’ of a new initiative begins to fade.

To continue the practice of SAFe effectively, and ensure the ongoing engagement of the workforce, leaders must now expand their view of the implementation. They can’t just rinse and repeat. They will need to maintain the energy and enthusiasm they are devoting to the short cycles of iterations and PIs, while setting their sights on the distant horizon of long-term sustainability. The mindset and process of ‘relentless improvement’ must now take root. This, of course, is synonymous with ‘continuous change.’ And that can be challenging for an enterprise.

In this final article in the Roadmap series, Sustain and Improve, we’ll suggest some key activities the enterprise can use to overcome those challenges and continuously sustain and improve its business performance. They include:

  • Foster relentless improvement and the Lean-Agile mindset
  • Implement Agile HR practices
  • Advance program execution and servant leadership skills
  • Measure and take action
  • Improve Agile technical practices
  • Focus on Agile architecture
  • Improve DevOps and continuous delivery capability
  • Reduce time to market with value stream mapping

Read the full article here.

We fully expect that the Implementation Roadmap will undergo its own relentless improvement as it continues to be tested in the field. As we work toward providing the best guidance possible for the SAFe community, we’d love to hear from you. Your thoughts and feedback on the Roadmap have been invaluable.

Stay SAFe!
—Dean and the Framework team




Categories: Blogs

Exploring Five Pair Programming Techniques

A collaboration by Antonio González Sanchis and Mario Moreira
Extreme Programming (XP) introduced a programming technique that’s been famous since its early days: pair programming. It sounds simple, two people working together with the same computer. However, what people don’t know is that there are many ways in which you can approach this technique. Let’s explore a few:

Driver-navigator:This is the best known style of pairing. It consists of one person ‘driving’, taking the keyboard and coding or doing the work, while the other one is ‘navigating’. The Navigator’s job is to pay attention to the work being done by the driver while keeping the big picture in mind.  They should guide the driver in the right direction. It is very important that driver explains every decision they make, otherwise the navigator might lose interest and may stop paying attention. It’s healthy to switch roles every now and then.

Ping-pong: For this approach you might need two keyboards connected to the same computer. In contrast to the driver-navigator mode, in ping-pong both people can be driving at any point in time. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.

Backseat navigator: A typical approach when there’s a new team member in the group or a junior colleague. The navigator (usually the more senior team member) tells the driver, who has the keyboard, what to do to solve a problem with every little detail. The navigator should provide insights on how to solve the problem but also on why that’s the best solution in mind. It’s a good way to ramp up new members in your team as they build relationships with other people in the team while learning about the working style.

Tour:If there is an even number of team members or someone who you used to pair with went on holidays, you are not going to stop working. However, when those people return or you start pairing with someone, you don’t want them to start right away. Therefore, a good way to start would be to do a ‘tour’ through the code or work you did in their absence. The person who doesn’t know the most about the work takes the keyboard and the mouse and starts driving through the code while the ‘expert’ acts as a navigator and explains every detail.

Distributed pairing: Often people tend to think pairing is for collocated teams but that’s not entirely true. While pairing face-to-face is definitely much more effective than remotely, there are many tools and ways colleagues can pair. A good suggestion would be to use a videoconference messaging tool with a screen sharing app that allows the navigator to see in real time what the driver is doing.
These are not the only pairing styles that you might encounter but they are the best known.  They are also the easier techniques to try when you want to start pair programming. Also, examples seem to focus on software development but pairing is applicable to almost every field.  For example if you are in marketing and are launching an email campaign, you can pair with someone to navigate through the email while you write it, etc.

There might be anti-patterns when pairing. For example, you might find cases when the navigator is ‘sleeping’. This means the navigator can be checking emails, texting or even coding in parallel without paying much attention to the driver. Try to identify the root causes of this behaviour before you jump in into action. Usually it might be because the driver is not explaining properly the reasons why he is doing a specific task in a particular way.

Lastly, keep in mind that while pair programming may work in every role or department, it might not be suitable for every work. There will be times when you just want to discuss the approach with the team and go do it by yourself. That’s also a way of getting feedback, which in the end is the main purpose of pair programming: getting feedback early.  

If you are interested in trying pair programming, the first thing to do is review the list of possible techniques (above) and select one that you will experiment with.  Then identify your pair.  Brainstorm on how you might approach pair programming, specify how long you will try your experiment, and begin.  
------------Learn more about Antonio González Sanchis at
Read more of Mario's article at: 
Categories: Blogs

Jobs don’t fit in neat little boxes.

Esther Derby - Sat, 04/15/2017 - 19:09

Most job descriptions decompose work into discrete chunks, clearly defining what each position must do. Competency models list required behaviors, seeking standardization across contexts. In essence, these models are akin to specifications for machine parts.

Complex knowledge work isn’t like that.

I prefer to think about jobs in terms of the work, impact on the organization, context, relationship, and collaboration. There’s a core of qualities, skills, experience, and demonstrated understanding necessary for the work. Context shapes what’s actually required to do the job and have an impact on the organization.

Sort of like a fried egg.

Doesn’t fit in a nice neat box, but closer to reality.

Job Descriptions vs. Jobs


© Esther for esther derby associates, inc., 2017. | Permalink | No comment | Add to
Post tags:

Feed enhanced by Better Feed from Ozh

Categories: Blogs

Velocity Calculus - The mathematical study of the changing software development effort by a team

Agile Complexification Inverter - Fri, 04/14/2017 - 21:39

In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity. For many, this exercise appears very academic. Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.

Velocity—the rate of change in the position of an object; a vector quantity, with both magnitude and direction. “Calculus is the mathematical study of change.” — Donald Latorre 
This pamphlet describes the method I use to teach beginning teams this one very important Scrum concept via a photo journal simulation.

Some of the basic reasons many teams are "doing it wrong"... (from my comment on Doc Norton's FB question: Hey social media friends, I am curious to hear about dysfunctions on agile teams related to use of velocity. What have you seen?

  • mgmt not understanding purpose of Velocity empirical measure;
  • teams using some bogus statistical manipulation called an average without the understanding of the constrains that an average is valid within;
  • SM allowing teams to carry over stories and get credit for multiple sprints within one measurement (lack of understanding of empirical);
  • pressure to give "credit" for effort but zero results - culture dynamic viscous feedback loop;
  • lack of understanding of the virtuous cycle that can be built with empirical measurement and understanding of trends;
  • no action to embrace the virtuous benefits of a measure-respond-adapt model (specifically story slicing to appropriate size)
... there's 6 - but saving the best for last:
  • breaking the basic tenants of the scrum estimation model - allow me to expand for those who have already condemned me for violating written (or suggesting unwritten) dogma...
    • a PBL item has a "size" before being Ready (a gate action) for planning;
    • the team adjusts the PBL item size any/ever time they touch the item and learn more about it (like at planning/grooming);
    • each item is sized based on effort/etc. from NOW (or start of sprint - a point in time) to DONE (never on past sunk cost effort);
    • empirical evidence and updated estimates are a good way to plan;
  • therefore carryover stories are resized before being brought into the next sprint - also reprioritized - and crying over spilt milk or lost effort credit is not allowed in baseball (or sprint planning)

Day 1 - Sprint Planning
A simulated sprint plan with four stories is developed. The team forecast they will do 26 points in this sprint.

Day 2
The team really gets to work.

Day 3
Little progress is visible, concern starts to show.

Day 4Do you feel the sprint progress starting to slide out of control?

Day 5About one half of the schedule is spent, but only one story is done.

Day 6The team has started work on all four stories, will this amount of ‘WIP’ come back to hurt them?

Day 7
Although two stories are now done, the time box is quickly expiring.

Day 8
The team is mired in the largest story.

Day 9The output of the sprint is quite fuzzy. What will be done for the demo, what do we do with the partially completed work?

Day 10
The Sprint Demo day. Three stories done (A, B, & D) get demoed to the PO and accepted.

Close the SprintCalculate the Velocity - a simple arithmetic sum.

Story C is resized given its known state and the effort to get it from here to done. 

What is done with the unfinished story? It goes back into the backlog and is ordered and resized.

Backlog grooming (refinement) is done to prepare for the next sprint planning session.

Trophies of accomplishments help motivation and release planning. Yesterday’s weather (pattern) predicts the next sprints velocity.

Sprint 2 Begins with Sprint PlanningDay 1Three stories are selected by the team.  Including the resized (now 8 points) story C.

Day 2
Work begins on yet another sprint.

Day 3
Work progresses on story tasks.

The cycles of days repeats and the next sprint completes.

Close Sprint 2Calculate the Velocity - a simple arithmetic sum.

In an alternative world we may do more complex calculus. But will it lead us to better predictability?

In this alternative world one wishes to receive partial credit for work attempted.  Yet the story was resized based upon the known state and getting it to done.

Simplicity is the ultimate sophistication. — Leonardo di Vinci 
Now let’s move from the empirical world of measurement and into the realm of lies.

Simply graphing the empirical results and using the human eye & mind to predict is more accurate than many peoples math.

Velocity is an optimistic measure. An early objective is to have a predictable team.

Velocity may be a good predictor of release duration. Yet it is always an optimistic predictor.

Variance Graphed: Pessimistic projection (red line) & optimistic projection (green line) of release duration.

While in the realm of fabrication of information — let’s better describe the summary average with it’s variance.

Categories: Blogs

Business Analysis Manifesto: the changing role of Business Analysis in an Agile organization

Xebia Blog - Fri, 04/14/2017 - 21:00

  The other day a discussion moved towards the -changing- role of Business Analysts in an Agile environment. I referred to the Business Analysis Manifesto. Created by and for Business Analysts, but never published. I realized I could share it with ‘the world’ and wrap it in blog-paper. So, this Business Analysis Manifesto is not […]

The post Business Analysis Manifesto: the changing role of Business Analysis in an Agile organization appeared first on Xebia Blog.

Categories: Companies

5 Kanban Strategies to Help IT Operations Teams Meet and Exceed Deadlines

What do you do when urgent work constantly interrupts planned project work? Time after time, you put...

The post 5 Kanban Strategies to Help IT Operations Teams Meet and Exceed Deadlines appeared first on Blog | LeanKit.

Categories: Companies

Team Size Matters, Reprise

Johanna Rothman - Thu, 04/13/2017 - 18:47

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. 

  • 4 people, (16-4)/2=6
  • 5 people, (25-5)/2=10
  • 6 people, (36-6)/2=15
  • 7 people, (49-7)/2=21
  • 8 people, (56-8)/2=24
  • 9 people, (81-9)/2=36
  • 10 people (100-10)/2=45

Here’s why the number of communication paths matter: we need to be able to depend on our team members to deliver. Often, that means we need to understand how they work. The more communication paths, the more the team might have trouble understanding who is doing what and when.

When team members pair, swarm, or mob, they have frequent interconnection points. By working together, they reduce the number of necessary communication paths. Maybe you can have a larger team if the team mobs. (I bet you don’t need a larger team then

Categories: Blogs

Practicing (subversive) Scrum: you CAN do it!

Learn more about transforming people, process and culture with the Real Agility Programphoto by V. Senykphoto by V. Senyk

by Jerry Doucett and Valerie Senyk

So you’ve taken Scrum training, received your industry certification, and perhaps even experienced being a Scrum team member. In your heart you believe Scrum is the right tool and approach for you, and you believe your current organization and your customers could really benefit from Scrum practices.

However, for whatever reason your organization is either hesitant to consider Scrum or outright believes it’s a bad idea. Perhaps there was an experience with a poorly executed pilot. Perhaps your leadership see it as being too risky.

What do you do?

This article explores how you could subversively practice ScrumMaster-ing in your workplace without getting into trouble or breaking the rules. Ssh…we won’t tell!

Before you even begin strategizing, you need to ensure that what you do aligns with the Scrum values, namely:


Doing Scrum subversively will certainly take considerable courage, focus and commitment on your part. Be aware you will be challenged to respect the existing organizational culture and norms, and they may push back on your efforts.

You also need to acknowledge that the very act of being subversive means you are not being completely open and transparent that you are practicing Scrum to the extent possible.

Or you could tell your workmates, “I’ve had this terrific training in Scrum and could we try a few of the techniques to see how they work?” Then introduce something as simple as time-boxing or holding retrospectives with your colleagues.

You will also want to ensure what you do is harmonious with Scrum Theory and the pillars of empirical process, which are:

1. Transparency 2. Inspection 3. Adaptation

Normally, one could say there’s a direct conflict between being transparent and being subversive. Keeping this in mind, it is imperative you be absolutely transparent on the actions you are taking and what the specific goals, outcomes or learnings are that you hope to achieve.

However, given the circumstances you’ll likely choose to not explicitly use Scrum terminology and language to describe what you are doing. In other words, describe the practices and activities that you are implementing or recommending, express their benefits and what you hope to accomplish, but don’t explicitly call them by their Scrum name.

As for Inspection and Adaptation, those approaches should be perfectly aligned with your intent to try to help your company become a learning organization. That means you will need to park your ego at the door and accept the results. If your learning shows your subversive Scrum activities do not provide the benefit you are aiming for, you will need to stop them regardless of whether you think they should work or not.

Let’s explore some activities and practices you may want to tactfully consider to help your organization benefit from Scrum (without actually “doing” Scrum).

1. Lead by Example

As someone that appreciates the values of Scrum, you should aim to educate others and provide them with a similar understanding. That means practicing them in how you show up and in everything you do, even explicitly calling out certain actions when they are a prime example (and of course, whenever it is appropriate).

This does not mean preaching! Instead, it could be sharing your thoughts about something when contributing to a decision, or simply pointing out when and how something that aligns with the values contributes to a better team, a better experience, or a better solution.

Leading by example also means being human and honest when mistakes are made or when failures occur. This can be particularly risky in an organization that has not embraced Agility, or where failure is frowned upon. That is where you need courage, and a commitment on your part to hold improvement of the work your organization does above your own individual career needs.

2. Communicate More

Make a concerted, conscious effort to communicate with your team and partners more. For example, get up out of your seat and spend more time in informal face-to-face discussions rather than sending e-mails or chat messages.

Perhaps you can have short, informal meetings with just the team either daily or several times a week to see what has been done, what still needs to be done, and what challenges the team is facing. The key here is to keep it mercifully short, focus on what needs to be done to move work forward, and define actions to address issues. Then always follow up and make sure the actions are being pursued and progress shared with the team.

3. Be Open And Transparent

Although you may consciously choose to not use the proper terminology and language of Scrum, the key is to always be honest about what it is you are trying to do, why it is important, and what the desired outcomes are.

To this end the goal should never simply be to have teams adopt Scrum. The goal should be to become a learning organization that “learns about learning”, constantly tries to improve, delivers value faster, and applies new knowledge in the best possible way. Scrum may be a fantastic catalyst for that, but there are many other approaches that will achieve similar results.

4. Use Better Meeting Practices

Another approach to consider is improve meeting experiences by time-boxing and defining specific scope for each meeting. Setting a time limit and specific outcomes for a discussion helps create a sense of urgency, manage expectations and focus the conversation on the most important topics. The facilitator will need to enforce these constraints if you really want to be successful, otherwise you lose the effectiveness of the practice.

5. Have One or More Key Stakeholders Empowered to Make Product Decisions

This may be a considerable challenge in organizations where there is little appetite or understanding about Agile practices and Scrum, but do what you can given your authority and influence. If possible, try to have a single voice (key stakeholder) defined as the person with the final authority on the product or service that your team is delivering. Then, work with that individual to set them up for success by connecting them with the other stakeholders, perhaps facilitating discussions with them, and showing the key person(s) effective techniques for prioritizing and rank-ordering the work that is being asked for.

6. Limit Efforts to What Matters Most

One practice that is important to apply, but often difficult to master, is focus. Limit work and discussions to the most important tasks and activities, and request that other discussions on lesser-important work be delayed. Always try to focus the conversation back to what is currently the most important work.

On occasion you may even want to point out times when plans were well-defined in advance but ultimately changed a lot when the actual work was in progress. This indicates the waste in planning too much up front and in constant task-switching. When done in conjunction with time-boxing this practice becomes a little easier.

On a macro scale, when possible try to limit development to smaller chunks of end-to-end deliverables. In other words, deliver small things often all the way to completion as much as possible (e.g. to a staging environment). Then show the outcome and deliverable to stakeholders and customers, explaining that although the final product may not be done, this is specifically to get them something fast and gather feedback.

7. Reflect on Learning

When possible, ensure that reviews of completed work happen frequently. Ensure the outcomes, functionality and value is shown and that learning (for the product as well as the methods) are part of the discussion.

Without becoming intrusive, seek stakeholder feedback frequently and informally. Then, be willing to demonstrate an ability to pivot plans based on that feedback.

As a team, hold informal retrospectives of how you worked together. If the term “retrospective” is contentious, consider calling them something else such as a debriefing or a reflection.

8. Visualize and Display Work

Have your own personal backlog and list of current activities visible at your desk. Use post-its to represent all work that you have on your plate, and ensure it is always up-to-date. Prioritize the work items you have coming up, and visually represent this as a rank-ordered list of things that you have to do.

It won’t take long for people around you to notice what you are doing and ask about it. Use this as a great opportunity to educate others on the values of transparency and focus.

9. Keep Your Team Size Appropriate

If you are on a particularly large team, see if it is possible to split that large team in to smaller groups. The benefit is more face-to-face time and interaction across the new team, an increased sense of belonging and commitment to the new team’s purpose, and it should also be easier (in theory anyway) to get decisions made and increase alignment.

The challenge will be finding a logical way to split the teams to mitigate dependencies of people, skills and products, and ensuring the new teams can still collaborate with one another. Geography might be a good way to split the team if you are distributed, but you would need to ensure all the skills to deliver the solution exist on all new teams.

10. Push for Automation

If you are in a development environment where tools, automation and engineering practices are not currently being used, and they could be of value to your organization, then start investigating whether it is possible. Tools and automation are not cheap nor are they easy to implement, but they dramatically encourage you and your teams to collaborate better and they enable the adoption of Scrum practices such as fast delivery of value.

Final Note

Be confident that your own creativity may help you unlock ways of practicing Scrum methodology without disrupting your organization’s practices.

You may or may not be able to implement all of the above actions but, as one Agile Coach likes to say, “it’s all about how YOU show up, how YOU are.” In the final analysis, your example, your enthusiasm, your courage will be the best you can offer.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Practicing (subversive) Scrum: you CAN do it! appeared first on Agile Advice.

Categories: Blogs

5 Agile Leadership Patterns

BigVisible Solutions :: An Agile Company - Thu, 04/13/2017 - 17:00

A epiphany came to Dan Greening in one of many conversations he had with Jeff Sutherland on the topic of why so many organizations claim to be Agile without actually being Agile. The epiphany was this: an Agile organization needs Agile leadership. It is common today for organizations to claim to have implemented Scrum and failed, then to move on to another framework like Kanban only to have that fail as well. These same organizations may then move on to Lean Startup. The trend lines in Dan’s research indicated peaks and valleys were huge as corporations hired on, and then fired off, mass quantities of coaches. Dan wanted to know why that was the case. After more research, he found corroborating evidence for his suspicions: businesses who retain their agility do so under the auspices of truly Agile leadership.


Brent Barton: Hi I’m Brent Barton and today I have Dan Greening. Hi Dan.

Dan Greening: Hey, man.

BB: You just finished an interesting talk on Agile leadership patterns.

DG: Yeah with Jeff Sutherland.

BB: That went well?

DG: Yeah, it went really well.

BB: I’m passionate about agile leadership, because as we get into bigger and more complex environments, it’s becoming more and more evident that they’re critical to our success.

DG: Right.

BB: Tell us more about your perspective on that.

DG: One of the things that I’ve discovered, and you’ve probably discovered this too, is that we think of Agile, at least initially, as an engineering problem. Okay, it takes a long time for us to do this, the projects sometimes fail, they’re overbudget and over-time. So we started out trying to fix engineering. And we did, largely. We have Scrum, Kanban, XP, all these other great things. But then, first of all, it’s hard to do, so we hire a bunch of coaches to do that and then it costs a lot of money. Then I started seeing large companies hiring massive numbers of coaches, an army of coaches, at millions of dollars per year in cost. They would hire them, they would convert the engineering department. Someone in the finance department would go, “Wow, this is really expensive. Do we have to keep these people around?” Someone says, “We’re Agile already — we don’t need them anymore, we’re converted.” The coaches go away and guess what? Agile would revert. We would get in the situation where the teams wouldn’t have this high level of Agile thinking anymore in the way that Agile would go. And then they would go, “Oh my god, our release times have gone from one month to six months, nine months, twelve months.” So, two years later, after they fired all the coaches, they go, “We better do something.” Someone says, “Well, that was Scum, now we ought to use Kanban.” So, they hire a bunch of Kanban people. Then I saw one recently where they go, “Yeah, that was Scrum and then we did Kanban, and now we should use something different called Lean Startup. That’s the thing!” And I’m going like, “That’s hilarious because Lean Startup is an Agile method but it’s not a replacement for Scrum or Kanban; it’s actually dealing with market-side stuff, product management. And so they can be used really effectively together. And then you see, you look at these peaks and valleys of hired coaches. What’s the issue here? So Jeff Sutherland and I have been hanging out and I’ve been complaining to Jeff for the last five years about this, and he said, “You know, I think one of the things is: who are the leaders?” And he and I started comparing notes, and we’re going, “Oh my god, is the leader Agile themselves? Do they run their company in an Agile way? Do they think about their work in an Agile way?” When we saw that, we saw that agility was retained. And often times they can create agility themselves and maintain it themselves. And then what we would also see is this pattern where a leader might get fired, or leave, or whatever, and then agility would disappear.


BB: What does it mean to be an Agile leader in the context you just described?

DG: That was my first cut. I said, “Ok, I want to tackle that.” Because I’ve been dealing with big companies: I’ve been working with Skype, Citrix and other companies like that. So I said, “What is it about this?” And then I realized, I didn’t really have a good definition for agility. I can go to the Agile manifesto and it’s got some guidance for software developers. If you read it, it’s all about software. I think finance people, marketing people, everybody can be Agile if it suits their economics needs, and it usually does. So, I said, “Before I even tackle leaders and enterprises, I’ve got to figure out what agility is and what it’s defined by.”

So, I looked at all of our Agile practices and what purposes they serve. And what I think of as “chaotic economies.” Production is a chaotic economy, and Scrum works really well for that. Market product management is a chaotic economy, and Lean Startup works really well for that. So, what’s going on there? It’s all about sensing, adapting, and creating new things for an economy and doing it fast enough that you can adapt to the changes that might be occurring. So I came up with five patterns and they’re actually really simple. The first thing is you have to measure some leading indicator about your economy. In scrum, it’s about production. We have to produce something and the big indicators are cost. A leading indicator of cost is velocity. That’s a primary metric. If you just use velocity, though, it gets a little perverse. You start doing high velocity and then you produce crap. So we have to have something else to balance that off to make it not so perverse, so we use defect rate. Then you have both of those and and then we go, “We want our people to be happy, because when they’re happy, they produce more creative output.” We add happiness. So, they’re three metrics that lots of people like to use, Jeff and I especially; velocity, happiness, and defect rate. That pattern, measuring [a] leading indicator, is step number one. If you don’t know what your economy is, why you are doing it and what are some leading indicators that you’re making the right choices — you’re doomed for Agile. You can’t do it.

The second thing is you have to experiment, you have to adaptively experiment to improve. When you do that, you’re looking at your metrics and you’re trying new things. Like our retrospectives. We try new Definitions of Done, Definitions of Ready. We see: does it improve things or not improve things? Today most retrospectives are pretty lame, I have to admit. A lot of people phone it in. Yet that’s the center piece of Scrum really. If you’re really doing a good retrospective, you’ll see this acceleration of velocity. If you’re phoning in your retrospective, you might be better than waterfall, but not by much. So that’s the experimentation side.

The third thing — and these three things give you agility — the third thing is limiting work in process. You can measure stuff and experiment, but if the length time or amount of work to run those experiments is too big, you’re going to be a lot slower than the chaotic economy that you live in. So, if you limit the work in process, you’re going to be fast enough, then you’re doing all the right things. My assertion is, if you’re doing those three things, you are Agile. The problem is, doing those three things is really hard.

BB: That’s true.

DG: Like, you’re measuring stuff and guess what? You’re starting to tell the truth, and people are getting embarrassed, and guess what? They really wish you weren’t doing that. So then you’re experimenting and guess what? Sometimes you fail and sometimes people are uncomfortable about that. And that uncomfortableness is another pressure to stop doing Agile. You’re limiting work in process. And the people are saying around you, “Oh my god, my project is so important. Can’t you do a little on my project?”

BB: Just fit that in. It’s not that big!

DG: Yeah. So there’s pressure everywhere to be not Agile. So those three things are hard, and I’ve realized we do things in Agile to reinforce it a little bit. And one of those things is we embrace collective responsibility. Here’s what I mean by that. When you join a team, you can say, “I’m a developer.” And another person can join the team and say, “I’m a tester.” Then you start doing your thing and the developer gets done. The testing doesn’t get done. You get to the end of the sprint, it doesn’t ship. Someone says, “Here’s a failure. We couldn’t ship it.” You go to the developer and ask, “What went wrong?” The developer blames somebody else. The developer says, “Not my problem, I’m a developer. It’s the tester that did it. The problem, though, is as your project matures, testing becomes more and more of a dominant factor.

BB: Right.

DG: So, we didn’t shift, this developer didn’t shift their responsibility over to deal with that. They just said, “My job is this.” So collective responsibility says I join this team and I agree — I write a contract by joining this team — that I will be personally responsible for the collective output of the team. That puts enormous pressure on individuals to really make up for deficiencies in the team. But the result is higher agility. Now people are adapting with the flow of work that’s coming into the team to deliver value. So, that fourth thing provides enormous stability for Agile teams and we see that in training. XP, it’s all about together as a team, collective code ownership —  as another subpattern of that.

BB: For sure.

DG: And then the last pattern is, you’re often working in a system that is limiting your agility. So here I am on a team and I depend on stuff from other teams, let’s say. And they are slow. And I’m going, “Okay, I’m Agile, I can just ship, ship, ship. But I keep depending on this stuff from this other group that is doing two-month sprints.” It takes them two months to actually give me something releasable. So, that pattern solves systemic problems. So now what’s happening instead of looking at my little team, I start looking around my team and say, “What’s going on in the system around me that is limiting my agility?” And it turns out there’s all these teams I depend on. And so what happens is that encourages people to go out and reach out to those teams and help them. So, famously, Toyota did this, when it was doing just-in-time manufacturing. It’s trying to build these cars, someone makes an order, and then you start doing all the stuff to build the car. Well, they would get all the way down to the tires, and then they would go, “We don’t build tires; we buy those.” So, they went out to the tire manufacturer and said, “Hey, could you make some tires for me? I just got an order.” The tire manufacturer goes, “We do this on a quarterly cycle. We sent you the memo; you didn’t read it. You’re supposed to pre-order however many tires you need for the cars you’re going to build. Well, how many cars are you going to build?” And Toyota goes, “We’re just-in-time — we don’t know!” So they finally got frustrated and said, “Well, I guess we could be a tire manufacturer, but we’re not great at that. Here’s the next best thing: we’ll go out and teach the tire manufacturer how to do just-in-time.” And that’s exactly what they did. And by doing that they actually created kind of an infrastructure of just-in-time in Japan. And we started seeing Honda and other car manufacturers start to adopt this strategy because they could. Their tire manufacturers were Agile and they were sitting there like, sitting on their butts really, but they were like, “Oh, we can do that. We have all these great service providers…”

So, those five things: measuring economic progress, so, leading indicators. Adaptively experimenting for improvement. Limit work in process. And now you are Agile. You won’t be able to keep it unless you do a couple more things: Embracing collective responsibility, creating a culture where individual people feel responsible. And finally, solving systemic problems. And that gets us back to leadership. Right? So, now I’m going, “This is great! I’ve got a definition of agility, I’ve got these patterns, and guess what? They’re totally scalable.” I can go to an individual and I can say, “Hey, Brent I can tell whether you’re Agile by just interviewing you and asking some questions about how you run your life.”

BB: Right.


DG: Or I could go to you as a team or as an executive and say, “Hey, let’s find out if your organization is Agile or not. What are you measuring? What are you experimenting on? What’s your work in process limit?” And this is important. It’s important on so many scales. One is, as an executive, do you have a team of people dealing with strategic work? I call them strategic Scrum teams, where you got a bunch of VPs or directors in a room and you’ve got strategic work and a backlog and you’re plowing through it and solving major problems for companies. Another thing you can do is, you’re hiring someone for a position in a company that is Agile. And I’m going, “You know what? You shouldn’t be hiring someone who answers those five questions in a funny way.” That’s how you tell they’re Agile, not ‘that they wrote on their resume, “I know Agile” or “I know Scrum” or whatever it is. CSM! Or I was a CEO at such a thing… It means nothing. Let’s find out the reality behind the system.

BB: Sounds like these are a consumable set of patterns for leaders to really evaluate and participate in the agility in an organization.

DG: Absolutely.

BB: That’s great. I’d love to probe further about the finance groups and all of these these other things and see how those teams are. We must do this again.

DG: Great to talk to you, Brent.

BB: Thanks, Dan.

Want more Agile Amped? Subscribe below!


The post 5 Agile Leadership Patterns appeared first on SolutionsIQ.

Categories: Companies

What’s The Easiest Way To Get Docker Into Production?

Derick Bailey - new ThoughtStream - Thu, 04/13/2017 - 15:00

Elton Stoneman  Docker in Production  Video Poster

… and once it’s in production, how do I manage, monitor and scale when I need to?

These are questions I’ve often been asked, and have asked several times. They are not questions for which I’ve had a good answer, though.

Sure, you can find all kinds of articles about container orchestration, management and auto-magically doing all kinds of awesome stuff at a massive scale. There are plenty of big talks from huge companies and well-known speakers on this. But that doesn’t help a developer on a small team, or someone working on their own. It doesn’t provide a simple answer for learning and growth, either.

And all these talks on the massive-scale auto-magic solutions never once helped me when I was looking at putting a single Docker image into a production environment.

So, how do you go from development to production?

And how do you grow your production environment as needed? When do you know you’re ready to use the next set of tools? And what are the next set of tools?

On March 14th, 2017, I interviewed Elton Stoneman from the Docker Developer Relations team, and we talked about exactly that – how to get Docker into production, after you’ve created your development image.

At a high level, this interview walks through what it takes to go from development to the most basic of production configurations. From there, it moves into a discussion of a more stable environment with Docker Swarm, deployment of multiple containers using a docker-compose.yml file, and then out to large-scale production and enterprise needs with Docker Datacenter.

Along the way, you’ll hear more about what “orchestration” is, get a clear understanding of how a Docker image can be monitored to ensure the application is responding correctly, and learn how to quickly and easily scale an application.

If you’ve ever wondered where to look next, after you’ve created your own Docker image and built an application into it, you’ll want to check out this interview.

Learn how to go from development to production with Elton Stoneman.

P.S. Be sure to read to the bottom of that page to find out how you can watch the interview for free!

The post What’s The Easiest Way To Get Docker Into Production? appeared first on

Categories: Blogs

Multiple Views of Truth are Perceptions

Agile Complexification Inverter - Wed, 04/12/2017 - 23:33
These are a few of the images that resonate with me. For me they are very close to a door of perception. Now I've never done a mescaline trip, so perhaps I've no clue to what a door frame of perception even looks like... but these images are pretty good with a few beers and some colleagues to discuss there deep meaning and what truth is. Would we even know the truth if it walked up and slapped our face?

Translated: "This is not a pipe"

Cover image of book: Godel Escher Bach

This is Truth; while this and that are true
In any article I write that mentions a door of perception - I would be remise if I didn't mention one of my all time favorite poets and musical group - Jim Morrison and the Doors.  Now do you know that the band is named for?

Aldous Huxley's The Doors of Perception
"Huxley concludes that mescaline is not enlightenment or the Beatific vision, but a "gratuitous grace" (a term taken from Thomas Aquinas' Summa Theologica).[50] It is not necessary but helpful, especially so for the intellectual, who can become the victim of words and symbols. Although systematic reasoning is important, direct perception has intrinsic value too. Finally, Huxley maintains that the person who has this experience will be transformed for the better."
See Also:

Godel Escher Bach An Eternal Golden Braid by Douglas Hofstadter
This Is Not a Pipe by Michel Foucault
Art of Rene Magritte
Categories: Blogs

SonarQube 6.3 in Screenshots

Sonar - Wed, 04/12/2017 - 16:55

The SonarSource team is proud to announce the release of SonarQube 6.3, which brings both interface and analysis improvements.

  • Project “Activity” page
  • More languages on board by default
  • Global search improvements
  • Backdating issues raised by new rules on old code
  • The return of UI extension points

Project “Activity” page

This version introduces an Activity page at the project level. It replaces the History page found in previous versions, but unlike the History page, Activity can be seen by all users with project permissions, not just admins.

The activity list starts on the project home page, replacing the Events list:

On the project home page, only the most recent analyses are shown, but click through on “Show More” or the new “Activity” menu item, and you land at the full list:

Admins will find here the full list of editing options they’re used to, and users will be able to see the list of analyses on file for a project for the first time!

More languages on board by default

SonarQube 6.3 now embeds the latest versions of most SonarSource code analyzers: SonarC#, SonarFlex, SonarJava, SonarJS, SonarPHP, and SonarPython. That means less setup work on new installations and on upgrades:

Global search improvements

6.3 also brings several improvements to global search. First, it’s now backed by Elasticsearch, so it’s fast. Making that switch allowed us to improve not just speed but, the results as well. Now you can search by multiple terms, and your results will be ordered relevance:

Backdating issues raised by new rules on old code

If you’re living by the Leak Period you know the pain of adding new rules to your quality profile: suddenly code you haven’t touched in months or even years has “new” issues – valid issues you need to silence somehow, either by marking them Won’t Fix, or by editing code you previously had no plan to touch. Because we dogfood new rules at SonarSource we felt this pain acutely.

Well, help is here. Starting with 6.3, SonarQube backdates issues raised by newly activated rules on old code to the line’s last commit date. No longer will you be forced to excavate old code to clean up a specious leak. Instead, you can activate new rules with abandon, knowing that the only issues that show up in the leak period will be the ones that actually belong there.

The return of UI extension points

6.3 is the first version to reach the target architecture of a UI written completely in JavaScript. As a consequence, we’ve been able to re-introduce the ability to extend the UI at both the global and project levels. The docs give the details on how to go about that.

That’s all, folks!

Its time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

Categories: Open Source

Deprecating the old Help Desk portal

TargetProcess - Edge of Chaos Blog - Tue, 04/11/2017 - 22:21

We released our Help Desk portal back in 2008. It was a great software that allowed external users to submit requests. Years passed, and it became more and more obsolete from both the technical and user perspectives. Rather than wade through technical debt to try and improve it, we released a separate Service Desk application that already has all the functionality of Help Desk, a better UI, and some cool new features such as custom fields and request types.

We probably should have dropped the old Help Desk back in December 2016, when Service Desk was officially out of beta. It's hard to do, since we sort of got attached to it over the years. Nothing lasts forever though, especially in the software business, so it's time to let it go. Apart from the infrastructure costs of hosting both versions of the software, we also have to maintain and update it to keep up with the latest changes in Targetprocess. For example, in our latest release (v.3.11.0) there were some changes to the way user information is stored, and the 'Forgot Password' button stopped working in Help Desk.

We cannot afford to lose focus at this point, so we are freezing the Help Desk and will completely remove it from our On-Demand servers on June 1st, 2017. What does this mean for you? Most likely, nothing new. If you're not using request management, or if you're already using Service Desk, you don't have to do anything. In case you're not sure, here's what Service Desk looks like:


If you are still using Help Desk, that means you will have to switch to Service Desk. All you need to do is activate it at Settings -> Service Desk, and all of your requests and projects will automatically transfer over. On-Premises customers can technically continue using the old Help Desk, though we do not see any good reason for it.

We hope you enjoy the new version of the software. If you have any reason you prefer the old one, please let us know.

Farewell, Help Desk. It's time to move on.

Categories: Companies

The remote backlog grooming / refinement session

Growing Agile - Tue, 04/11/2017 - 16:04

A few weeks ago a company contacted us. They needed help. They were busy with a super important project and wanted to do it the agile way, and were a bit stuck. The business and management people were in City A and the dev team were in City B. They had a bit of previous agile experience in the development team but no-one else really did.

We suggested a remote call with everyone in both cities to understand where they were at. We had no idea what would happen, we were simply there to understand and perhaps guide. This 2 hour session turned out to be our best remote session yet!

As preparation for the call, we sent an email a few days before asking everyone to install Zoom (our remote conference call tool of choice) and asking that everyone dials in by themselves using a headset even if they are in the same location. We also gave them a trello board to connect to.

We started the call with everyone introducing themselves and what they do, so that we had a better idea of who we were talking to. The developers all dialed in. The business in City A dialed in together from a conference room, and a manager dialed in separately.

Immediately we could notice the difference in call quality. The group in City A was hard to hear, you were not always sure who was speaking. We also learned that Zoom adjusts volume, so every time someone far from the speaker spoke Zoom adjusted which meant we could barely hear the next person.

Tip 1 – insist that everyone dials in themselves, rather than using a conference phone in a meeting room. (Though having them experience this was also a valuable lesson.)

We then checked that everyone could access the Trello board and shared the link again. We gave everyone 5 minutes of silence to brainstorm talking points or questions onto the trello board. We needed to mute the group in City A as they had one PC and were chatting to type up and disrupting everyone else. (We needed to do this for every “silent brainstorm” we had, and mostly we forgot to unmute them until it was pointed out – so if you have this problem, don’t forget to unmute!).

After the brainstorm we asked everyone to vote for their top 3 topics. There is a nifty power-up for Trello that allows this called “voting”. Once again the group in City A were disadvantaged as they could only vote once for a topic as they had one PC, we solved this by asking them to type in the chat window what they want to vote on and we just included that in the count.

We then spent the next 90 minutes or so talking about their number 1 topic…. though I think almost every topic was touched on!

This is the fun part – we wanted to make this interactive and visual to keep everyones attention – so we were trying something new. We had attempted this a few days before and the technology had failed spectacularly – so we were prepared with plan B, but never needed it

Categories: Companies

The remote backlog grooming / refinement session

Growing Agile - Tue, 04/11/2017 - 16:04
A few weeks ago a company contacted us. They needed help. They were busy with a super important project and wanted to do it the agile way, and were a bit stuck. The business and management people were in City A and the dev team were in City B. They had a bit of previous agile […]
Categories: Companies

Are You Struggling To Learn ES6/ES7 Features Without Breaking Your Current Projects?

Derick Bailey - new ThoughtStream - Mon, 04/10/2017 - 23:13

Sometimes it seems like it’s impossible to learn the new stuff without breaking your existing work… installing new versions of Node.js, updating Babel.js plugins, enabling experimental features with command-line flags?


It’s far too easy to break things in your current project.

But I’ve been working on something that might help make this easier. Before I announce it, though, I need your help.

I’d like to ask you a question about what you’re struggling with, in learning new and upcoming features of ES6, ES7 and beyond.

Just enter your email address in this box, below, and I’ll send you a quick, 1-question survey.

The post Are You Struggling To Learn ES6/ES7 Features Without Breaking Your Current Projects? appeared first on

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.