Skip to content


Making Mad Men More Agile

TV Agile - Mon, 05/30/2016 - 18:04
The Mad Men era in advertising agencies is truly on the way out and collaborative agency models are spreading faster than the traditional top down approach. Agile principles can be used to great effect in advertising agencies and not only for digital projects but also to increase productivity and foster collaboration, creativity and innovation. In […]
Categories: Blogs

Using RabbitMQ To Share Resources Between Resource-Intensive Requests

Derick Bailey - new ThoughtStream - Mon, 05/30/2016 - 13:30

A question was asked on StackOverflow about managing long-running, resource intensive processes in a way that does not hog up all resources for a given request. That is, in a scenario where a lot of work must be done and it will take a long time, how can you have multiple users served and handled at the same time, without one of them having to wait for their work to begin?


This can be a difficult question to answer, at times. Sometimes a set of requests must be run serially, and there’s nothing you can do about it. In the case of the StackOverflow question, however, there was a specific scenario listed that can be managed in a “fair” way, with limited resources for handling the requests.

The Scenario: Emptying Trashcans

The original question and scenario are as follows:

I’m looking to solve a problem that I have with the FIFO nature of messaging severs and queues. In some cases, I’d like to distribute the messages in a queue to the pool of consumers on a criteria other than the message order it was delivered in. Ideally, this would prevent users from hogging shared resources in the system. Take this overly simplified scenario:

  • There is a feature within an application where a user can empty their trash can
  • This event dispatches a DELETE message for each item in trash can
  • The consumers for this queue invoke a web service that has a rate limited API

Given that each user can have very large volumes of messages in their trash can, what options do we have to allow concurrent processing of each trash can without regard to the enqueue time? It seems to me that there are a few obvious solutions:

  • Create a separate queue and pool of consumers for each user
  • Randomize the message delivery from a single queue to a single pool of consumers

In our case, creating a separate queue and managing the consumers for each user really isn’t practical. It can be done but I think I really prefer the second option if it’s reasonable. We’re using RabbitMQ but not necessarily tied to it if there is a technology more suited to this task.

Message Priorities And Timeouts?

As a first suggestion or idea to consider, the person asking the question talks about using message priorities and TTL (time-to-live) settings:

I’m entertaining the idea of using Rabbit’s message priorities to help randomize delivery. By randomly assigning a message a priority between 1 and 10, this should help distribute the messages. The problem with this method is that the messages with the lowest priority may be stuck in the queue forever if the queue is never completely emptied. I thought I could use a TTL on the message and then re-queue the message with an escalated priority but I noticed this in the docs:

Messages which should expire will still only expire from the head of the queue. This means that unlike with normal queues, even per-queue TTL can lead to expired lower-priority messages getting stuck behind non-expired higher priority ones. These messages will never be delivered, but they will appear in queue statistics.

This should generally be avoided, for the reasons mentioned in the docs. There’s too much potential for problems with messages never being delivered.

Timeout is meant to tell RabbitMQ that a message doesn’t need to be processed – or that it needs to be routed to a dead letter queue so that it can be processed by some other code. 

Priorities may solve part of the problem, but would introduce a scenario where files never get processed. If you have a priority 1 message sitting back in the queue somewhere, and you keep putting priority 2, 3, 5, 10, etc. into the queue, the 1 might not be processed.

For my money, I would suggest a different approach: sending delete requests serially, for a single file. 

Single Delete-File Requests

In this scenario, I would suggest taking a multi-step approach to the problem using the idea of a “saga” (aka a long-running workflow object).

When a user wants to delete their trashcan, you send a single message through RabbitMQ to a service that can handle the delete process. That service would create an instance of the DeleteTrashcan saga for that user’s trashcan.

The DeleteTrashcan saga would gather a list of all files in the trashcan that need to be deleted. Then it would start doing the real work by sending a single request to delete the first file in the list.

With each request to delete a single file, the saga waits for a response to say the file was deleted.

When the saga receives the response message to say the previous file has been deleted, it sends out the next request to delete the next file.

Once all the files are deleted, the saga updates itself (and any other part of the system, as needed) to say the trash can is empty.

How This Handles Multiple Users

When you have a single user requesting a delete, things will happen fairly quickly for them. They will get their trash emptied soon, as all of the delete-file requests in the queue will belong to that user:

u1 = User 1 Trashcan Delete Request

When there are multiple users requesting a delete, the process of sending one delete-file request at a time means each user will have an equal chance of having their request handled next.

For example, two users could have their requests intermingled, like this:

u1 = User 1 Trashcan Delete Request

u2 = User 2 Trashcan Delete Request

Note that the requests for the 2nd user don’t start until some time after the requests from the first user. As soon as the second user makes the request to delete the trashcan, though, the individual delete-file requests for that user start to show up in the queue. This happens because u1 is only sending 1 delete-file request at a time, allowing u2 to have requests show up as needed.

Over-all, it will take a little longer for each person’s trashcan to be emptied, but they will see progress sooner rather than later. That’s an important aspect of people thinking the system is fast / responsive to their request.

But, this setup isn’t without potential problems.

Optimizing: Small File Set vs Large File Set

In a scenario where you have a small number of users with a small number of files, the above solution may prove to be slower than if you deleted all the files at once.

After all, there will be more messages sent across RabbitMQ – at least 2 for every file that needs to be deleted (one delete request, one delete confirmation response)

To optimize this, you could do a couple of things:

  • Have a minimum trashcan size before you split up the work like this. below that minimum, you just delete it all at once
  • Chunk the work into groups of files, instead of one at a time (maybe 10 or 100 files would be a better group size, than 1 file at a time)

Either (or both) of these solutions would help to improve the over-all performance of the process by batching the work and reducing the number of messages being sent. You would need to do some testing in your actual scenario to see which of these (or maybe both) would help and at what settings, though.

Beyond the batching optimization, there is at least one additional problem you may face – too many users.

The Too-Many-Users Problem

If you have 2 or 3 users requesting deletes, it won’t be a big deal. Each will have their files deleted in a fairly short amount of time.

But if you have 100 or 1000 users requesting deletes, it could take a very long time for an individual to get their trashcan emptied – or even started! 

In this situation, you may need to have a introduce level controlling process where all requests to empty trashcans would be managed.

This would be yet another Saga to rate-limit the number of active DeleteTrashcan sagas.

For example, if you have 100 active requests for deleting trashcans, the rate-limiting saga may only start 10 of them. With 10 running, it would wait for one to finish before starting the next one.

This would introduce some delay to processing the requests. But it has the potential to reduce the over-all time it takes to delete an individual trashcan.

Again, you would need to test your actual scenario to see if this is needed and see what the limits should be, for performance reasons.

Scaling Up and Out

One additional consideration in the performance of these resource-intensive requests is that of scaling up and out.

Scaling up is the idea of buying “larger” (more resources) servers to handle the requests. Instead of having a server with 64GB of memory and 8 CPU cores, perhaps a box with 256GB of memory and 32 CPU cores would perform better and allow you to increase the number of concurrent requests.

While scaling up can increase the effectiveness of an individual process instance, it becomes expensive and has limitations in the amount of memory, CPU, etc.

Scaling out may be a preferable method in some cases, then.

This is the idea that you buy many smaller boxes and load balance between all of them, instead of relying on one box to do all the work. 

For example, instead of buying one box with 256GB memory and 32 cores, you could buy 10 boxes with 32GB of memory and 4 cores each. This would create a total processing capacity that is slightly larger than the one box, while providing the ability to add more processing capacity by adding more boxes. 

Scaling your system up and/or out may help to alleviate the resource sharing problem, but likely won’t eliminate it. If you’re dealing with a situation like this, a good setup to divide and batch the processing between users will likely reap rewards in the long-run. 

Many Considerations, Many Possible Solutions

There are many things that need to be considered in resource intensive requests.

  • The number of users, the number of steps that need to be taken
  • The resources used by each of those steps
  • Whether or not individual steps can be done in parallel or must be done serially
  • … and so much more

Ultimately, the solution I describe here was not suitable for the person that asked, due to some additional constraints. They did, however, find a good solution using networking “fair queueing” patterns. 

You can read more about fair queueing with this post and this video.

Because each scenario is going to have different needs and different challenges, you will likely end up with a different solution, again. That’s ok.

Design patterns, such as Sagas and fair queueing, are not meant to be all-in-one solutions. They are meant to be options that should be considered.

Having tools in your toolbox, like Sagas and batch processing, however, will give you options to consider when looking at these situations. 

Categories: Blogs

Have impediments solved by Scrum team members

Ben Linders - Mon, 05/30/2016 - 12:52

Scrum team members take actionIn my workshops I often play the impediment game with teams. In that game team members discuss impediments that happen during Scrum sprints or Kanban flows, and decide how to deal with them and who should solve the impediment. The “who” is most often “any team member”. But in practice I see that teams struggle with impediments, and often expect the Scrum master or a manager to solve them. Let’s explore what can be done to have impediments solved by Scrum team members.

What I have seen in all of my workshops where I played the impediment game is that, for 90% or more of the actions needed,  team members agree that any team member can do the action. Occasionally there’s an action which they think should be done by the Scrum master. Assigning the action to somebody outside the team is rare. Even if the team needs a manager’s decision they will allocate the action to a team member who will arrange for support and assure follow up.


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

What stops team members from taking action

Given that I hear team members saying in my workshops that they are willing and able to solve impediments, why does it still happen so often in practice that Scrum masters are the ones taking action? Or that actions are assigned to or picked up by managers outside the team?

What I hear when I’m coaching people is that it has to do with habits, it’s something that people are used to. In the old days with waterfall projects their manager would take action when there’s a problem, or tell them to do something. So team members start off in agile by expecting the same from the Scrum master or manager.

Another reason I hear is that team members are scared to take responsibility. They think they are not allowed to decide and take action. When they did it before, they were questioned or overruled, so they stopped taking actions themselves. So now they behave as they feel the organization expects from them.

This is a cultural problem, not a skills or capability issue. In my workshops I don’t have to train people how to take action. They know that very well! I create a safe setting using the impediment game, and when they play the game they go into their natural behavior which is to solve problems themselves. They do solve problems when at home, in their sport teams or when they practice their hobbies. Somehow they switch it of when they walk into the office. Let’s remove that switch!

Anything that slows down a team needs to be dealt with. Solving impediments matters! Handling impediments is a key value for teams and organizations to increase their agility. and yes, you need to have everybody on board to deal with problems effectively, including team members.

Have impediments solved by Scrum team members

Earlier I wrote about why Scrum masters shouldn’t be the one solving all impediments. There’s value in the Scrum master helping team members to find ways, and be an example, but it should be about teaching people how to fish in stead of feeding them. You do not want the Scrum master to be a bottle neck for the team. Self organizing means that the team as a whole is capable to deal with impediments.

The solution to have team members solving impediments is actually quite easy: stop Scrum masters and managers from solving impediments! Get rid of the mindset that it’s a Scrum master’s or manager’s task to solve problems; any professional can and should do that. Give space to team members so that they dare to take action.

These are things that help you enable and inspire team members to take action:

If team members are taking action, then you don’t need full time Scrum masters. I’ve worked in very mature teams and we didn’t need a Scrum master, since everybody could and would do the things that Scrum masters do. When something needed to be done we quickly decided who would do it, e.g. who would be most suited or by taking turns.

If you are still not convinced that impediments can and should be solved by team members after reading this article, then I invite you to come to one of my workshops to play the impediment game and find out

Categories: Blogs


Henrik Kniberg's blog - Mon, 05/30/2016 - 11:08


Categories: Blogs

Links for 2016-05-29 []

Zachariah Young - Mon, 05/30/2016 - 09:00
Categories: Blogs

Classical Agile Estimating

Agile Estimator - Sun, 05/29/2016 - 17:08

Release Burn Down Chart

Is agile too new to talk about “classical” agile estimating? Not really. The agile manifesto was copyrighted in 2001. I became aware of agile development in 2003. In either case, agile has been around for more than 10 years. This means that there has been time for people to develop true expertise in agile software development. It also means that it is well past the time we need to consider some refinements to the parts of agile development that do not work as well as they could. The focus of this blog is obviously the estimating portions of the agile development process. I will summarize them here. I will also explain why some of the techniques do not work as well as we though they would. I will also talk a little bit about some fundamental principles, like user stories. This is done to insure that we are all picturing the same things when we talk about estimating them. Most of what is written will apply to any agile approach, but some of the terminology is based on Scrum. Face it, Scrum is to agile methodologies as Microsoft Office is to productivity software. Like it or not, it is the clear winner.

Scrum, and every other agile development methodology, is driven by user stories. They usually have the format type of user, will be able to perform action. For example, as a salesman, I can input customer information. Some people elaborate on a user story by adding a reason. For example, as a salesman, I can input customer information so that I can track my interactions until the sale closes. In 2003, we stressed that agile developers should be co-located with their users. The user story cards were simply used to spur conversations between the developers and the users. They were written on cards because they were not intended to be permanent documents. Today, most agile development is distributed. User stories are kept in Microsoft Office documents or in specialized agile planning tools. However, the principles are still the same. The user stories are not intended to be requirements documents. They are really more important as planning documents. User stories are explained in two of Mike Cohn’s books: User Stories Applied and Agile Estimating and Planning. The second book talks about how they are used for project estimating.

In Agile Estimating and Planning, Mike Cohn gives and interesting case study where a software company undertakes to develop a new game. They establish an initial set of user stories. However, their estimate is more driven by their experience developing a different game. For the most part, they are using the same development team and development technologies. The rules of the game are different, but they can extrapolate. The case study uses games that are not completely explained. But for illustration purposes, suppose the team had just programmed a checker playing game and now it was going to attempt a chess game. There are two different checkers pieces, a piece and a piece that has been turned into a king. Chess has six different types of pieces. Some have different types of moves depending upon board configurations, like the castling of a king. In any case, there would be some ways in which you could make analogies between the two games in order to estimate how long the new game might take to develop. This is estimating by analogy, but int only works if you have similar projects, developed by similar teams in a similar fashion. It does not help a product owner sitting in his office with a few dozen user stories before the team has been established or the initial technical decisions have been made.

In the case study just mentioned, the team is in place and they have experience with a similar project. Developing initial user stories is not too difficult. This is also true when planning an enhancement project. The underlying application is available. It is somewhat straight forward to write user stories to describe the enhancements. But what about a new application? What about the time before the team is hired or assigned?  At this point, the user stories must be written by the users. They can be lead through the process by the product owner. In any case, developing the initial user stories is hard, and estimating them is harder. My thesis, An approach to Early Lifecycle Estimating for Agile Projects, describes a collaborative technique called Elf Poker which develops user stories and an estimate. Note that my thesis committee would not let me call it a game. However, most teams in this situation use some type of workshop technique to develop the user stories and then use planning poker to assign story points to each of the end user stories.

User stories are usually estimated in terms of story points. Story points represent the amount of effort that will be necessary to implement a user story. However, it is not measured in hours or any other unit of time. It is merely a relative measure. For example, if one story is assigned 8 story points, then a story that could be implemented in one-half of the time would be 3 or 4 or 5 story points. Why the imprecision associated with story points. It is by design. Story points can only be 0 (for extremely small), 1, 2, 3, 5, 8, 13, 20, 40, or 100. Some practitioners use a value of 4 instead of both 3 and 5. In either case, the objective is to have relative sizes, but not to bog down trying to assign values like 25 vs. 30. This is usually more precision than the team can realistically assign anyway. Agile teams usually assign use case points by playing a game like planning poker. Each player gets cards with the possible story point values from above. Each round begins by having someone read a story card, the team asks questions and discusses their assumptions, and then each person places the card corresponding to their choice for story points in front of them. When everyone has picked a value, the cards are turned over. In the rare cases where everyone agrees, the value is assigned. Other times, the people with the lowest and highest value explain what they thought and then everyone puts out their possibly new values. This may happen a two or three times in an effort to reach consensus. If no consensus is reached, the dealer chooses a value by averaging the players’ choices or by taking the most popular answer.

In agile development, an application is developed in a series of releases. I have lost track of the number of releases that Microsoft Excel has been through. No one knows how many more to expect. A release requires a certain set of user stories to be implemented. Each story has an estimate in story points. Thus the release requires a certain number of story points to be implemented.  Each release is developed in a series of iterations or sprints. The sprints are fixed in terms of calendar time, usually one or two weeks. If  sprints in your organization are two weeks long, then when the two weeks are done, the sprint is done. One facet of agile estimating is to decide how many sprints will be necessary to implement the next release. If you are planning to complete 10 story points worth of user stories in a sprint, the product owner chooses the stories to work on. If all the stories are not completed, then the unfinished ones go back into the product backlog. If they are done early, the product owner selects additional stories to be worked on. In any case, if you knew the number of story points that would be implemented in each release, you could develop a burn down chart like the one at the top of this post. You would begin with the number of story points that had been implemented in the completed iterations. Then you would forecast the number that would be delivered in future sprints. As Joe Bergin said in our Pace University agile courses years ago, “the best forecast of tomorrow’s weather is today’s.” Use the velocity from your most recent sprint to figure out how many more sprints will be required.

Each sprint must also be planned. Developers are typically not tasked with implementing user stories. The user stories are decomposed into technical tasks that must be accomplished. Each technical task is assigned to a developer or two. There is an ideal time associated with each task. Kent Beck defined ideal time as the amount of time the task would “take without distractions or disasters.” No one can do 80 hours of task work in a 2 week sprint. The team must figure out what its velocity, or number of ideal hours accomplished, has been in previous sprints and apply that number to this sprint. Some teams develop a burn down chart similar to the above, with cumulative task hours remaining on the vertical access and number of days in the sprint on the horizontal one.

Sometime during the sprint, there is a point where the team looks at their backlog of user stories. This is usually a meeting called story time or story grooming. The development teams will straighten out the user stories. Sometimes they break a story into smaller stories because they understand the situation better. They will re-estimate the stories. This step is necessary because the team must validate that the sprint they are involved with is consistent with the needs of the release as a whole. Development teams usually hate this step. At the very least, it distracts they from the sprint that they are focused on. Even worse, it calls on them redo their estimates. The developers usually do not like doing estimates. They are usually not good at it. There are two reasons that they are not usually good at it. First, they are trained developers, not trained estimators. Second, because they are on the team, they can fall victim to a phenomenon called groupthink. They cannot be depended on to deliver an impartial estimate.

Groupthink can best be illustrated with a personal story. Years ago, I was asked to look at a large development project and decide if and when it might be completed. As part of my process for doing this, I would meet with the team leads and try to get a feel for the functionality that they were working on. Often, I did not know the team leads despite the fact that they worked for the same company that I did.  They often worked for other offices. However, I knew one of the leads. He was intelligent and I felt I could depend on him to be truthful. As I interviewed him, I realized that he did not understand the functionality he was attempting to develop. This is not unheard of. He realized the same thing. At that point, he said that it was too bad that I was not going to be in town the following week. I asked if he was having some meeting to establish the functionality. No, he said, the system would be in production and he could show me how it worked. He was a victim of groupthink. The team bought into this utterly impossible schedule. No one could picture anything else. I figured they were a year away from production. The client killed the project in five more months.

Retrospectives are part of the agile process. We must look at the way that we develop systems and decide what is working and what is not. It is time to look at the estimating portions of agile development. Does it need to be repaired? If it is not broke, then there is no need to fix it. Or, is it one of the distractions that prevents us from getting 80 hours of task work done during a two week sprint? Is estimating always necessary? When it is necessary, who should do it? How? Please let me know what your teams are doing that is different from the approach described here.

Categories: Blogs

Submit a session to XP Days Benelux

Ben Linders - Sun, 05/29/2016 - 09:53

xpdayslogo-web_small 2016I have submitted several talks and workshops to the XP Days Benelux 2016 conference. This conference, which will be held November 24 – 25 in Heeze, the Netherlands, is looking for presenters that want to facilitate highly interactive sessions where everyone participates and learns from each other.

I’ve submitted two sessions to the XP Days 2016 conference:


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Everything you always wanted to know about … Agile Retrospectives!

Are your teams doing retrospectives? Do they like them? Are they valuable? These are the questions that I’m asking all around the world when I give presentations or workshops on retrospectives. Often hands start to go down on the 2nd question, and even more on the 3rd one. Teams try to do them, but many don’t like them and they don’t see the value.

Come to this session if you want to be inspired on how to spice up your retrospectives and keep them valuable for your teams.

Agile Self-Assessment Game

Agile is a journey, not a destination. Sure, but how to travel the journey, and where to go next?

There isn’t a silver bullet or standard route to become agile, you have to find your own way. A route description won’t help you. You need an “agile map” that inspires you with ideas and suggestions on where to go to support your journey. The Agile Self-Assessment game is here for you.

Come play the Agile Self-Assessment game in teams to discover how agile you are and what you can do to increase your agility.

XP Days Benelux is one of my favorite conferences. There’s an outstanding program year after year. The atmosphere is great, attendants are eager to share their experiences and learn from each other. Attendance is limited to 150 people which makes it easy to network with people, even for introverts.

I’ve done several talks and workshops at the XP Days Benelux over the years:

I also covered the conference from 2012 onward for, see XP Days Benelux coverage by Ben Linders.

Submission review at XP Days Benelux is fully transparent. Members of the program committee and those who have submitted can review submissions. They use the perfection game as a positive way to give feedback. Submitters are encouraged to review each other work, and they actually do: I’ve received valuable feedback from several submitters already and I gave feedback to talks submitted by others. The feedback helps me to improve my submissions and make them “perfect” before the selection process starts. To my knowledge the XP Days Benelux is the only conference who has this, and I like it!

The call for sessions closes on June 17 at midnight. Sessions that have been submitted before that date can be updated until August 5. Don’t miss the deadline, submit a session at XP Days Benelux today.

And after you’ve submitted, feel free to give feedback on my sessions :-).

Categories: Blogs

Workshops at the Agile Greece Summit 2016

Ben Linders - Sat, 05/28/2016 - 13:38

Agile Greece Summit logoI’m giving two workshops on Agile Retrospectives and Value with Agile and Lean at the Agile Greece Summit 2016. Ticket sales has started, normal price for each workshop is €480. You get a discount if you also attend the Agile Greece Summit on September. All events take place in Athens, the beautiful capital of Greece.

Valuable Agile Retrospectives for Teams – September 15


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Agile Retrospectives help teams to continuously improve by reflecting at the end of each iteration to learn what is going well and what can be improved, and to do improvement actions in the next iteration. Retrospective facilitators need to have a toolbox of retrospective exercises and the skills to design and lead valuable agile retrospectives. In the workshop Valuable Agile Retrospectives for Teams you will practice exercises for facilitating retrospectives in teams. More info ->

Getting More out of Agile and Lean – September 17

The practices in the workshop Getting More out of Agile and Lean will help you to develop the right products for your business and customers, reduce your delivery time, increase the quality of your software, and create happy high performing teams. More info ->

Agile Greece Summit 2016 is an international event with world class agile experts. Designed for executives, team leaders, project managers, developers. After giving a talk and two successful workshops at the first Agile Greece Summit in 2015 I was invited back to the 2016 Agile Greece Summit.

You can register for the Agile Greece Summit workshops and conference. Early bird tickets are available until June 15!


Categories: Blogs

Links for 2016-05-27 []

Zachariah Young - Sat, 05/28/2016 - 09:00
Categories: Blogs

What Is Success, In Software?

Derick Bailey - new ThoughtStream - Fri, 05/27/2016 - 18:23

When we look at a project and attempt to determine whether or not it is successful, there are many aspects and considerations that have to be judged. It can be difficult to judge, as well – and often depends on your perspective in relation to the software.

Are you the customer? Or the developer? The marketer, or the support staff?

Ultimately, the perspective that we have will shape our focus, and having the right focus can make or break the success of our software.

So, what is success in software?

Find out in this episode of Thoughts On Code.

Categories: Blogs

A Dream Deferred

This is a hard blog post to write. I’ve actually pondered for some time whether I should write this down and publish it or just bottle it up and deal with it like we did with a similar situation two and a half years ago. I’m not one to shame companies, stir the pot up and make a scene. But I still feel some seething anger about what I perceived as discrimination then and I feel just as angry about this new situation I’m writing about today. After some reflection I’ve decided to simply tell this story and my hope is that, while venting, perhaps find some positive resolution. You may say I’m twisting events or that I’m over-reacting. You may put my wife’s character and capabilities into question. It is what is and sometimes I think it’s worth it to just share a story. To put today’s story into context I think it is best to start from the beginning, talk about the experience I bottled up and then describe today’s scenario. I’ll draw my own conclusion while you may draw your own.

My wife is a very ambitious woman. Born in a refugee camp by two parents who met after losing their loved ones under the Khmer Rouge regime she was born a fighter. She survived a bout of lung cancer when she was only two years old and to this day has only one lung. She graduated college with a Bachelor’s in Mathematic and in Computer Science. When we worked together I was easily attracted to her ambition, intelligence and genuine concern for others. She always gives a twenty dollar bill to the homeless on the street. When she encounters a veteran or military personnel in uniform in public she always thanks them for their service. But I always loved how great she was to work with… we had so much fun attending conferences together and even gave a joint presentation on Behavior Driven Development with Scala at Strange Loop back in 2010.

Where I’m going with this is my wife has very specific career goals. Sure it can be fun to be an engineer but at one point or another one has a natural desire to move up. The employer we both worked at in the past unfortunately had a very flat structure with little upward momentum. So she began hunting and landed an engineering team lead position at another local company. She spent her days mentoring junior developers on practices like test driven development, object oriented design, patterns, etc. She also provided career guidance and even sent one of her developers to management training and put him in charge of some projects to give him experience. As a side story, he went on to become a team lead himself who I hear has been doing a pretty good job. Suffice to say, she really enjoyed this position and often said she was “living the dream.”

Conflict and Discord

Looking back I think sometimes the source of the conflict between Than and her manager was the fact that Than’s ambition is very aggressive and she’s not beyond doing what it takes to get things done. I think an amusing story is when her team had five different product owners say “this is a top priority from our CEO” in different meetings, she got back to her desk, picked up the phone and called the company CEO directly and chatted with him about it and how each five priorities can’t be the top and they need to be prioritized. He really appreciated her bluntness and worked with her to re-prioritize a bit. Her manager gave her a comment that the next time she should go through her.

It probably also didn’t help that her team was very strong willed and unafraid to go against Cargo Cult practices and shake up the status quo. But I always heard good things independently from people on her team. They really looked up to her and respected how much she stood up for them. She never backed down and was always willing to fight for her team when she had to. She never got a bad review and members of the executive team really liked her. Her manager once confided in her that sometimes she felt somewhat intimidated by Than because of her knowledge, experience and aggressiveness.

Something Strange Comes This Way

Than’s team kept growing and at one point was the largest team. I think they had a good ten or twelve people and I know at least two or three had specifically requested a transfer to be on her team. However as other teams began to work on new projects members started being “borrowed” off her team. It began downsizing. Six. Four. Two. This started becoming a little stressful to her. What began as an innocuous “Brian has great knowledge of the LMD subsystem so we’ll loan him out to this project to rewrite LMD” had trickled to no team projects… just support tickets. My wife sensed something was up… perhaps a downsize? She told her manager in her one on one that if there was no reason for her team to exist and they were keeping it place just to let her keep her position they should just disband it. And her manager did with a sigh of relief.

I keep looking back on this incident. Out of six or so teams the only team to be downsized and eventually disbanded was the one with a strong, female, dark skinned Asian. None of the other Caucasian males (who I might add had a lot less experience than my wife does) had this situation closing in on them. However I think I could have accepted if they had used this opportunity to perhaps promote my wife to a position better suited for her. Perhaps the Agile Coach position to transform the department in the same way she had transformed her team? They were looking to add that position and even the CTO mentioned that he thought she’d be a good fit.

In what will go down as perhaps one of the puzzling “promotions” I’ve ever witnessed, she was moved to a Business Analyst position. While this position was dressed as a promotion (after all, her salary remained the same, right?) the truth is that she’d be on the same level as her previous direct report; a business analyst that she successfully trained. I still find this highly puzzling, perhaps her manager thought that she’d be a good fit because she did so well training her business analyst? Her days were pretty much filled with nothing but doing business analyst type tasks and continuing to work the support queue her team used to own (but all by herself).

It should come as no surprise that this was a miserable state of affairs and after about two or three months she turned in her resignation letter. Like I said Than is very ambitious and is not content to what is a dead end. And we could both see that this recent “promotion” was nothing more than a dead end. We moved on. She found an agile coaching position that was located two hours east in St. Louis and gladly took it as an opportunity to move forward in her career.

Over that year I kept feeling anger but remained cool. “Cooler heads always prevail.” is the motto I’ve always lived by. But I cannot help but keep looking back and wondering. Was this what discrimination looks like? She never had a bad review. Everyone on her team thought she was fantastic. Yet at the end of the day she… a dark skinned Asian female who had clawed her way up from poverty, the daughter of elderly refugees… was the only team lead to face a demotion. I was so mad. I wanted to breath smoke. I wanted to grab someone and yell “She deserves better than that. For all her hard work, this just is not how you should treat someone!”

But every time I reflect on the situation, it is a permanent gray area. Maybe it was discrimination. Maybe it was just dumb luck. If we cut it another way, perhaps a team had to be cut and it just had to be hers? Why should another team lead have to suffer just because they were born white and male? There’s also the nagging feeling that of all the team leads, Than as the one who came into conflict the most with her manager. Anyhow this whole situation was topped off with Than’s mother passing away and, three weeks after the funeral, her manager’s response to her resignation letter was “I knew this was coming sooner or later.”

Oh well. As Frank Underwood would say, I don’t cry over what happened in kindergarten.

Cooler Heads Prevail

Than loved her new job. She felt like she was making a difference again. As an engineering coach she put together classes to teach TDD, patterns and all that good stuff. She worked with various teams across multiple data centers to organize their work into backlogs and remove road blocks. She got lots of praise from upper management. Her career was moving again. She even showed me a letter, written by someone who had attended her classes, state that he was able to take what he learned in her class and land a different job with his salary doubled. It was really touching to see how much of a difference she was making in other’s lives.

We did have a difficulty of her living in St. Louis during the week and being home only on the weekend but we worked through it. Richard lived with her in St. Louis while Caitlynn and I spent time together working on her speech issues. We cherished our time together as much as possible on the weekends and, when school schedule would allow it, Caitlynn and I would pack up and drive down to St. Louis and I’d work from T-Rex or a random coffeeshop and meet up with her afterwards. Sure it was hard but we made it work.

Unfortunately the contract took the turn that some contracts just do. The consulting company was bought out by a larger company. The contract’s future was put into doubt. If she remained she might be looking at having to consult on site somewhere very far away. Just to give an idea of where she might wind up, the other coach she worked with was sent to Minnesota. After some clever accounting (more on that one day) we made it so that she could simply take the summer off to rebalance and figure out what she wanted to do next. Before we did this though she did take an interview at another company. As she walked out to her car the recruiter called and told her that they were very impressed. The client would love to build a team around her. When could she start? We discussed it at length and in the end she decided it’d be best to take the summer off so she could refocus. A small sabbatical of sorts.

Summer Revelations

That summer Than found out an interesting revelation that really wasn’t quite a revelation given her entire life to this point. She was just way too ambitious to be a stay at home mom. Now this isn’t meant in any shape to be an attack on those who do chose to stay at home. But she just couldn’t tolerate not bringing income into the household. I kept trying to convince her to perhaps work on a startup idea or something but she just couldn’t focus being in a completely work free situation for the first time in her life. Her parents were too elderly to work and when she turned 18 she was the sole provider of her household. She moved them out of Section Eight housing and into a trailer working at Target while attending college. And after she landed her first job out of college she moved them into their first new construction home at the age of 23. Being without a job and not being the breadwinner of the family was a completely alien experience for her.

At the end of the summer she decided to re-enter the field. As luck would have it, around this time the same recruiter who had tried to hire her before the summer started reached out. “Are you still available?” They still hadn’t filled that position and still felt that Than was the perfect fit. I drove down to St. Louis with her and worked on my laptop in a Starbucks while she met with the recruiter and Director of Engineering. They spoke for about an hour and were all smiles and excitement. As we left Than offered to buy me a nice bottle of scotch to celebrate, she had accepted their offer and was going to head up a Quality Engineering team at this new client. They’d build a team around her and after a trial period convert her to a full time manager.

Life Goes On

The remainder of the year was somewhat uneventful. She loved her new job and her new co-workers. With the salary she was now commanding she decided to simply drive back and forth (a total commute of four hours) every day because moving her career forward was worth it. We did look at houses in St. Louis but in the end just really loved our home and our daughter loved her school and friends. So we stayed put and she continued commuting. The engineering team had some growing pains here and there but they worked though them. Her director became VP of engineering. We attended dinners and bourbon tastings with the product owners she worked with. Life was good.

After some time, her contract had reached the point where she was able to convert over to full time. HR pushed really hard to get her to convert but she kept holding out. She wasn’t sure if she wanted to put roots down or not. We discussed it and in the end she decided well, it has been a nice place to work. It pays well. And they do have that sweet $10,000 signing bonus (repayable if you leave earlier than two years) that could definitely help with our deck restoration project. Plus it was a true management position that she could grow in. After much deliberation she signed the employment offer and returned it. This is where things took a quite distinct turn for the worse.

A New Director

Only a week after she converted to a full employee she received the news. A certain rockstar programmer that her employer had been trying to recruit for some time had finally accepted an offer. He’d take on the VP of Engineering’s previous director role. She was a bit uneasy about this because her VP had told someone else that if he kept up the good work he might transition him into this role and this seemed like a broken promise. She was also a little displeased that the team was 100% uninvolved with his hiring process but after meeting with him for lunch she walked away feeling that this guy was pretty alright.

By the new director’s second day he told Than that he didn’t really see a need for her team and would be disbanding it. She’d convert to an engineer and he told her, straight up, that he thinks she’ll do good being in engineering. When she told him this would be a step backwards quite a bit since the past 4 years she’s been grooming herself for management he told her “Well, if you do good and prove yourself there might be a path forward for some kind of promotion in the future.” When she pulled up in the driveway that evening I met her in the driveway and saw she still had tears in her eyes. She felt cheated. Lied to. To take a management position and have the rug pulled out from under her only three weeks later. Eleven years of engineering experience, four years leading teams and coaching, and to be told in the end that she needs to prove herself. What more does one have to prove?

Again I have a gnawing feeling. I want to push it out of my head, I want to make the excuses. “Flat organization structures are all the rage these days,” I think. Maybe he’s just doing this because that’s his philosophy. Then more circumstantial evidence builds up. None of the other managers are being demoted and my wife feels like she’s being picked on. She’s texted multiple teammates asking if she’s being petty by pushing back against her demotion. They’ve all told her not at all and even added that they’re surprised she’s not fighting back harder.

Are we coming face to face with discrimination again? Am I imagining things? I want to believe that her director is just oblivious to what he’s doing to her. It’s easy to meet someone, so far removed from their engineering origins, and come to a conclusion that they’re not that smart. That they have something to prove. He doesn’t know us. He doesn’t know my wife’s past. He doesn’t know that she co-founded a technical user group with me 6 years ago that is still going strong. He doesn’t know she was a judge at startup weekend that had it’s first place winner actually land $5.5 million in VC funding today. He doesn’t know that she’s very respected amongst so many people in our field.

Earlier today I read a very long blog post about discrimination another woman faced at a company and I began seeing some familiar narratives. Both her director and VP are projecting the perception that she’s the one causing problems. That somehow complaining about being demoted only three weeks after signing on is being “petty”. She’s being singled out as the one who is stirring the pot. Today they made the announcement that she’s transitioning to engineering in two weeks and she went to the bathroom and just cried. She feels so defeated and even asked me if she’s really that bad? Should she just exit this field altogether?

In a lot of ways I’m reminded of a poem by Langston Hughes that I first heard during my freshman year of college that really put the hook in me.

What happens to a dream deferred?

Does it dry up
like a raisin in the sun?
Or fester like a sore—
And then run?
Does it stink like rotten meat?
Or crust and sugar over—
like a syrupy sweet?

Maybe it just sags
like a heavy load.

Or does it explode?

The Road Forward

Sometimes our dreams and career goals have their ups and downs. Sometimes we take two steps forward and then have to take three back. Like I told my wife while calming her, only 4 years ago I found myself exiting a one-on-one with my manager and taking a long walk down the road wondering if maybe I should pursue a different career. Maybe I’m somehow just not cut for this field. Thankfully I lucked out because after that moment a friend’s startup really started to take off and they reached out asking me if I’d like to be their first engineering hire. If I hadn’t been in such a low point of my career I likely would have said no and bypassed what has been the best 4 years of my career.

Back to my wife’s situation, to say my anger has been simmering is an understatement. Yeah I lodge a few angry tweets here and there as I’m wont to do. But being negative really doesn’t solve much. Twitter is full of people who I can look at a long list of complaints of injustice and that’s just all they focus on day in and day out. Sure simmering in anger might feel good but it’s just not constructive in the long run.

I advised her that the situation definitely is toxic and it’s time to move on. But I just wish there was a way to make her get past the feeling of worthlessness. It sticks for awhile. It stuck two years ago and it’s sticking now. Everywhere I look in our industry we talk about diversity. “How can we attract more women to this field?” we ask ourselves curiously.

Like I said, perhaps this is all circumstantial. Perhaps you’ll say my wife just isn’t good at what she does. Maybe you’ll say like her director told her that she needs to prove herself. Maybe you’ll say she’s being petty. I’ve come to my conclusion and my conclusion is sexism. Discrimination. Call me a liar and social justice warrior of sorts if it makes you sleep better at night. I’ve simply chosen to call a spade a spade and will call it out.

We won’t take this lying down though and we won’t go silently into the night. We’re survivors. We’re a team and we don’t stop fighting. I’ll be dedicating the next several days to finding her something even better than what she thought she had with this lousy position. You might think less of me for sitting down and airing all of this but so be it. I stand up for those I love. I also can’t help but think that perhaps just distilling all my feelings about this situation into words will be more constructive than silently bottling it up like last time. I don’t want my daughter to ever have to face situations where it really is debatable if one is facing a demotion for anything other than performance. I’m not terribly worried though… my wife and I are both fighters. I am one hundred percent confident that she’ll come out on top.

These situations have left me with a final thought. In a field that has so many problems attracting and retaining diversity it is hard to imagine why when one is faced with so many set backs that leaving the industry is anything else but a logical conclusion. I don’t mean to be yet another voice beating a dead horse but it’s really time we started doing better.

Categories: Blogs

The Diagnosis and Treatment of Bimodal IT

Leading Answers - Mike Griffiths - Thu, 05/26/2016 - 05:35
Is it just me, or does Bimodal IT sound like a mental health condition? Unfortunate name aside, it has been adopted by companies reluctant to embrace agile but looking for a halfway-house / best-of-both-worlds solution. In my last post I... Mike Griffiths
Categories: Blogs

The X-Matrix Strategy Deployment Model

AvailAgility - Karl Scotland - Wed, 05/25/2016 - 23:46

There is a model for Strategy Deployment that sits behind the X-Matrix that is worth explaining in more detail as a way of understanding why it is designed the way it is, and how to use it. It is built around describing four types of elements – which I call results, strategies, outcomes and tactics – and how they fit together.

Before we start, lets get the George Box aphorism out of the way:

All models are wrong; some models are useful

Results represent the organisational impact you want to have. They are lagging indicators, success or failure only being declared at the end of the journey. They usually reflect the nature of the business and its economics.

The Results are implemented by Strategies

Strategies are constraints which guide how you achieve the results. They are enabling, allowing a range of possible solutions (as opposed to governing, limiting to a specific solution). Thus they guide decisions on where to focus attention (and hence also where not to focus attention).

The Strategies lead to Outcomes

Outcomes provide evidence that the strategies are working. They are leading indicators of whether the results can be achieved ahead of time. They describe the capabilities that the organisation requires in order to be successful.

The right Outcomes will generate the successful Results.

Screen Shot 2016-05-25 at 20.47.46

Of course the Strategies don’t directly lead to Outcomes. Some form of action has to take place. Thus the Strategies are actually implemented by Tactics.

Tactics are the activities that take place to implement change. They are experiments which test hypothesis on how to achieve the outcomes. The represent the investments in the improvement work that is being done.

Therefore, it is the Tactics that generate the Outcomes and ultimately lead to the Results.

Screen Shot 2016-05-25 at 20.48.11

For change to be successful, there should be a correlation between the various elements in this model (and it should be remembered that correlation is not causation). Each element will have some level of contribution to another. This will range from strong or direct, to weak or indirect, or there may sometimes be none. You could also say that the correlations are Probable, Possible, or Plausible. All together there should be coherence (albeit messy) to the way all the elements fit together.

Screen Shot 2016-05-25 at 20.48.32

By starting with Results, moving on to Strategies and Outcomes and leaving Tactics until last, there is a greater chance that the Tactics chosen are ones which do implement the Strategies and generate the Outcomes. The intent is to avoid premature convergence or retrospective coherence when identifying the Tactics. It is very easy to hastily jump to the wrong conclusions about what the Tactics should be, and then justify them based on the Strategies.

Even if you don’t use the X-Matrix explicitly, understanding this model can be useful for asking questions about change and improvement.

  • What end results are you hoping to achieve?
  • What are your strategies to deliver them?
  • What intermediate outcomes will show you are on the right path?
  • What tactics are you using to move forward?
  • How do all these pieces fit together?

If you can answer these questions, then you should be able to populate an X-Matrix. I will work through an example in an future post.

X-Matrix Simple

Categories: Blogs

Seven Ps for Profound Change

Esther Derby - Wed, 05/25/2016 - 22:38

Captured from my keynote at Big Apple Scrum Day, May 17, 2016.Seven Ps of Change

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

Feed enhanced by Better Feed from Ozh

Categories: Blogs

Agile Change or Adoption: Create a Vision

Notes from a Tool User - Mark Levison - Wed, 05/25/2016 - 11:35

(Continued from Agile Change or Adoption Always Starts with Why: Part 1, Part 2, Part 3)

Most organizational change effort starts with a vision. But problems arise if the vision was created by a few executives who went off-site, as that can result in a vision that doesn’t address the problems felt by the doers at the team level, and it isn’t articulated in a way that makes sense to them.

Instead of inviting just the senior executive team, we need a workshop that involves senior management, middle management, and a fair representation of the doers (e.g. developers, testers, support staff).

Then we need to define our vision collaboratively. Any of the familiar Agile approaches for creating vision (e.g. Innovation Games: Product Box or Prune the Product Tree, or Roman Pichler’s Vision Board) are effective choices. The goal is to create an initial vision with buy-in from all, and that can be easily explained/understood by even those who weren’t present.

But after you create the vision, you have to communicate clearly about it, otherwise the change you hope to generate is at risk.

Traditionally a town hall style event is used to announce a change. The CEO gives a speech, followed by several other executives, and then questions are invited from the floor. But few real questions follow, since attendees haven’t had time to digest or discuss the implications of the change. This isn’t collaborative and doesn’t even qualify as dialogue. It is purely a control and communications mechanism.

Catchball from Hoshin Kanri management (Japanese name for Toyota’s Strategic planning technique) is one collaborative approach to be considered as an alternative. Catchball is a fact-based strategic discussion process that gets Senior Management to sit down with Team Members. Senior Management show their vision, then they metaphorically “throw the ball” – i.e. pass the information back to the Team for their response. Team Members “catch the ball” and break down the vision into smaller digestible parts. They throw the figurative ball back to Senior Management, who review the approach to see if it will meet their needs. The ball is bounced back and forth until both groups are satisfied.[1]

The key point here is that the vision wasn’t just explained – much like creating an effective user story, the vision was treated as an invitation to a conversation. Also like effective User Story conversations, they’re best tested by creating specific concrete examples that reveal whether all parties are describing the same thing.

Case Study
At the WorldsSmallestOnlineBookStore, John, our intrepid former ScrumMaster and now Agile Coach, organizes a Vision Workshop. The goal is to decide as a group what they’re trying to achieve with the significant organizational change they’ve taken on.

John has invited 20 people to the event and asks them to self-organize into three to four teams. Each must have at least one executive, one middle manager, and two doers. Beyond that, he lets people choose which group they want to work with.

His framing question: “In two years and one day we’re part of a better organization, how did we improve? Did we:

  • become more resilient?
  • improve quality?
  • create faster time to market?
  • have better employee retention?

Each team is challenged to create a “Product Box” that illustrates the organizational changes they would like to see.

–           One team creates a box that shows a customer abandoning a purchase, and then a bigger picture of many happier customers. An arrow indicates the change from unhappy to happy.

–           Another team shows quality changing from a rubber stamp, to being built into every brick in a structure.

–           The last team shows a box with images on two sides. On the first side there is a solid brick wall with moss grown all over it. Many of the bricks are old and chipped. At the bottom of the box is a tiny clean section of the wall where the bricks have been repaired. It says “Agile”. On the other side of the box the team shows a wall largely cleaned of moss and with many repaired bricks. They explain that the moss was the past practices that were holding all the teams back. Once cleaned, the teams – both product development and operational – were able to repair many of the bricks.

After an hour of work, each team shares their vision with the others and explains what each element represents. They return to their tables and update their own vision based on what they discovered from their peers.

Finally, they come back together at the end to select a box that best represents their overall vision. (This is done by consensus and occasionally a consensus can’t be reached). In our case, they decide that a combination of the first two boxes best represents their vision.  The team that created the last box hasn’t done bad work, they just didn’t sell their peers on selecting it and the idea it represented. Sometimes you can have a great idea but others can’t see it and buy into it.


Image attribution: Agile Pain Relief Consulting

[1] Use the Catchball Process to Reduce Ambiguity – Tim McMahon
Categories: Blogs

My OSS CI/CD Pipeline

Jimmy Bogard - Tue, 05/24/2016 - 23:39

As far back as I’ve been doing open source, I’ve borrowed other project’s build scripts. Because build scripts are almost always committed with source control, you get to see not only other projects’ code, but how they build, test and package their code as well.

And with any long-lived project, I’ve changed the build process for my projects more times than I care to count. AutoMapper, that I can remember, started off on NAnt (yes, it’s that old).

These days, I try to make the pipeline as simple as possible, and AppVeyor has been a big help with that goal.

The CI Pipeline

For my OSS projects, all work, including my own, goes through a branch and pull request. Some source control hosts allow you to enforce this behavior, including GitHub. I tend to leave this off on OSS, since it’s usually only me that has commit rights to the main project.

All of my OSS projects are now on the soon-to-be-defunct project.json, and all are either strictly project.json or a mix of main project being project.json and others being regular .csproj. Taking MediatR as the example, it’s entirely project.json, while AutoMapper has a mix for testing purposes.

Regardless, I still rely on a build script to execute a build that happens both on the local dev machine and the server. For MediatR, I opted for just a plain PowerShell script that I borrowed from projects online.  The build script really represents my build pipeline in its entirety, and it’s important for me that this build script actually live as part of my source code and not tied up in a build server. Its steps are:

  • Clean
  • Initialize
  • Build
  • Test
  • Package

Not very exciting, and similar to many other pipelines I’ve seen (in fact, I borrow a lot of ideas from Maven, which has a predefined pipeline).

The script for me then looks pretty straightfoward:

# Clean
if(Test-Path .\artifacts) { Remove-Item .\artifacts -Force -Recurse }

# Initialize

exec { & dotnet restore }

# Build

# Test
exec { & dotnet test .\test\MediatR.Tests -c Release }

# Package
$revision = @{ $true = $env:APPVEYOR_BUILD_NUMBER; $false = 1 }[$env:APPVEYOR_BUILD_NUMBER -ne $NULL];
$revision = "{0:D4}" -f [convert]::ToInt32($revision, 10)

exec { & dotnet pack .\src\MediatR -c Release -o .\artifacts --version-suffix=$revision }

Cleaning is just removing an artifacts folder, where I put completed packages. Initialization is installing required PowerShell modules and running a “dotnet restore” on the root solution.

Building is just msbuild on the solution, executed through a PS module, which MSbuild defers to the dotnet CLI as needed. Testing is the “dotnet test” command against xUnit. Finally, packaging is “dotnet pack”, passing in a special version number I get from AppVeyor.

As part of my builds, I include the incremental build number in my packages. Because of how SemVer works, I need to make sure the build number is alphabetical, so I prefix a build number with leading zeroes, and “57” becomes “0057”.

In my project.json file, I’ve set the version up so that the version from the build gets substituted at package time. But my project.json file determines the major/minor/revision:

  "version": "4.0.0-beta-*",
  "authors": [ "Jeremy D. Miller", "Joshua Flanagan", "Josh Arnold" ],
  "packOptions": {
    "owners": [ "Jeremy D. Miller", "Jimmy Bogard" ],
    "licenseUrl": "",
    "projectUrl": "",
    "iconUrl": "",
    "tags": [ "html", "ASP.NET MVC" ]

This build script is used not just locally, but on the server as well. That way I can ensure I’m running the exact same build process reproducibly in both places.

The CD Pipeline

The next part is interesting, as I’m using AppVeyor to be my CI/CD pipeline, depending on how it detects changes. My goal with my CI/CD pipeline are:

  • Pull requests each build, and I can see their status inside GitHub
  • Pull requests do not push a package (but can create a package)
  • Merges to master push packages to MyGet
  • Tags to master push packages to NuGet

I used to push *all* packages to NuGet, but what wound up happening is I would have to move slower with changes because things would just “show up” on people before I had a chance to fully think through the changes to the public.

I still have pre-release packages, but these are a bit more thought-out than I have had in the past.

Finally, because I’m using AppVeyor, my entire build configuration lives in an “appveyor.yml” file that lives with my source control. Here’s MediatR’s:

version: '{build}'
  do_not_increment_build_number: true
  - master
  disable_publish_on_pr: true
- ps: .\Build.ps1
test: off
- path: .\artifacts\**\*.nupkg
  name: NuGet
- provider: NuGet
    secure: zKeQZmIv9PaozHQRJmrlRHN+jMCI64Uvzmb/vwePdXFR5CUNEHalnZdOCg0vrh8t
  skip_symbols: true
    branch: master
- provider: NuGet
  name: production
    secure: t3blEIQiDIYjjWhOSTTtrcAnzJkmSi+0zYPxC1v4RDzm6oI/gIpD6ZtrOGsYu2jE
    branch: master
    appveyor_repo_tag: true

First, the build version I set to be just the build number. Because my project.json file drives the package/assembly version, I don’t need anything more complicated here. I also don’t want any other branches built, just master and pull requests. This makes sure that I can still create branches/PRs inside the same repository without having to be forced to use a second repository.

The build/test/artifacts should be self-explanatory, I want everything flowing through the build script so I don’t want AppVeyor discovering and trying to figure things out itself. Explicit is better.

Finally, the deployments. I want every package to go to MyGet, but only tagged commits to go to NuGet. The first deploy configuration is the MyGet configuration, that deploys only on master to my MyGet configuration (with user-specific encrypted API key). The second is the NuGet configuration, to only deploy if AppVeyor sees a tag.

For public releases, I:

  • Update the project.json as necessary, potentially removing the asterisk for the version
  • Commit, tag the commit, and push both the commit and the tag.

With this setup, the MyGet feed contains *all* packages, not just the CI ones. The NuGet feed is then just a “curated” feed of packages of more official packages.

The last part of a release, publicizing it, is a little bit more work. I still like GitHub releases but haven’t found yet a great way of automating a “tag the commit and create a release” process. Instead, I use the tool GitHubReleaseNotes to create the markdown of a release based on the tags I apply to my issues for a release. Finally, I’ll make sure that I update any documentation in the wiki for a release.

I like where I’ve ended up so far, and there’s always room for improvement, but it’s a far cry from when I used to have to manually package and push to NuGet.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Communities of Practice Revisited

Agile Product Owner - Tue, 05/24/2016 - 22:35

Hello SAFe community!

I’m Steve Mayner. I recently joined Scaled Agile, Inc. after years as an SPC and SAFe® Gold Partner. Shortly after I came on board I was given the opportunity to help improve a few of the framework articles. We’re excited to share with you our updated insights on Communities of Practice. This new article provides deeper grounding in the CoP body of knowledge, and also offers specific step-by-step guidance for forming, growing, and managing healthy communities. You will also see specific examples that illustrate how CoPs can add value to ARTs as part of a healthy SAFe practice.

Promoting vibrant CoPs can go a long way towards realizing the ideals of Principle #8 – Unlock the intrinsic motivation of knowledge workers. As rewarding as work within the Agile team or the program team might be, practitioners thrive when they are constantly growing their skills and networking with other people who share common interests. CoP members bring that learning and enthusiasm back to their ART work, benefitting the entire program. CoPs are absolutely a win-win proposition for SAFe organizations and their team members!

As always, we look forward to your comments and perspectives on this new content!

Enjoy, and stay SAFe!

Steve Mayner
Senior SAFe® Program Consultant
Scaled Agile, Inc.

Categories: Blogs

Yet Another Boring Discussion

TV Agile - Tue, 05/24/2016 - 18:22
How comes that when 10 people gather to discuss a problem usually only 3 or 4 of them really participate? And why the rest looks so bored? Let us discuss how to turn our oh-no-yet-again-a-boring-discussion into something much more exciting, and with better chances of finding good solutions to the problem at hand. Video producer: […]
Categories: Blogs

Looking for an Agile Developer

Scrum Breakfast - Tue, 05/24/2016 - 17:53
As Product Owner for the Scrum Breakfast Club, I want an Agile software developer,  At the Scrum Breakfast Club, our goal is to enable people and companies to become Agile. We need some software to help us make that happen. How do you find an Agile Developer?

When I have looked for a development partner in the past, I have always started what skills, passion and personality am I looking for.

First, let's talk about what this project is not:
  • This is not about creating a pretty website. This is about building the pipes between the various components.
If the following points describe you, we would like to talk to you (must):
  • We need to be able communicate in English. (I have tried working through an interpreter, but I have not found it to work well).
  • Our basic flow is Scrum and we do short sprints. We are not dogmatic, but we want to produce working software at least once per week. We would like you to know what Agile is about before we start.
  • Our Product Owner cares about quality and robustness. So we would like someone who is into TDD, BDD or one of their cousins. 
  • Interest in the work (which is mostly about the plumbing right now!). We are looking at making WordPress plugins for own use and other glue. So the basic skills are PHP and TDD or BDD.
If the following points describe you, you are in a great position to get the assignment.
    • Happy to work in a virtual team. Our team is based in locations from Europe to South East Asia. We use Skype, Hangout, Trello, and various cloud services. 
    • Happy with workloads of varying intensity. We have a clear project now, so you'll be pretty busy. I expect we are looking at a one to two month engagement. After that, we'll see. Maybe there will be phases where we are just in maintenance mode. We do expect a long life for our project and would like to come back to you when we need your skills again!
    • We would prefer someone is independent or in a small partnership. Someone who has control over their own time. You'll be dealing with Principals, and we'd like to deal with a Principal too. 
    • Last but not least, we are looking for good chemistry. We want work to be fun! Actually, this is a must, too!
    Does this resonate with you? Would you like to be collaborate with an Agile team?
    How to contact usTweet a screen shot of your latest daily build or other evidence that you know how to build reliable code! Just include @peterstev and @bindzus and #SBCDEV in the tweet, and we'll reach out to you!

    Update 30.5.2016: Updated to better communicate our goals and priorities.

    Categories: Blogs