Skip to content

Feed aggregator

Are you the “Scrum Police” ?

Growing Agile - Tue, 05/31/2016 - 12:27
  I remember my first job as a ScrumMaster. I took it very seriously. I saw my job as being the custodian of Scrum, and ensuring everyone was doing it correctly. Does any of the following sound familiar to you? Make sure all the Scrum meetings are set up and rooms booked One minute before […]
Categories: Companies

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

#No Projects – Teams not Projects

Scrum Expert - Mon, 05/30/2016 - 17:58
Allan Kelly outlines the #NoProjects agenda and discusses the role of teams as the unit of production and the team life cycle. Good projects make for bad software. Software which is useful is used and demands change, stop changing it and you kill it. In a world without projects how do you manage work? The answer is teams. Teams are the means of production, work should be based around teams and teams should be stable. Video producer: http://agileonthebeach.com/ Further reading: Managing Beyond Projects – #NoProjects
Categories: Communities

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?

Mine

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
|u1|u1|u1|u1|u1|u1|u1|u1|u1|u1done|

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
|u1|u1|u1|u1|u1|u1|u2|u2|u1|u2|u2|u1|u2|u1|u1done|u2|u2|u2|u2|u2done|

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.


advertisement:

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

Misalignment

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

Misalignment

Categories: Blogs

Scrum Day San Diego, San Diego, USA, June 17 2016

Scrum Expert - Mon, 05/30/2016 - 10:30
The Scrum Day San Diego is a one-day conference that discusses Scrum, Lean and all things Agile in San Diego County. This single-track conference will be your opportunity to hear how other people from San Diego County navigated Agile software development steps as they share their stories. Learn from people who have been there and done that. In the agenda of the Scrum Day San Diego you can find topics like “Improve your Communication with Coaching Skills”, “The Stability States of Scrum: Two Keys to Building High Performing Teams”, “Coaching in the Context of your Culture”, “A Bad Start:  Why Agile Teams Ignore 75% of Their Customers and What to Do About It”, “Lifting Off: Launching Teams That Soar!”, “Developing Business Agility with Scrum – Hit The Ground Running”, “Agile Jumpstart and the KJ Prioritization”, “Continuous Improvement: Mitchell’s Journey from Waterfall to SAFe”. Web site: http://scrumdaysandiego.com/ Location for the Scrum Day San Diego conference: Marina Village Conference Center, 1936 Quivira Way, San Diego, CA 92109
Categories: Communities

Agile Israel, Tel Aviv, Israel, June 22 2016

Scrum Expert - Mon, 05/30/2016 - 10:00
Agile Israel is a one-day conference that discusses Agile, Scrum and Lean topics. It aims to attract Agile Managers, Scrum Masters, Product Owners and Coaches to discuss and network around these themes. In the agenda of the Agile Israel conference you can find topics like “Modern Agile”, “How to make sure you scaled Agile safely”, “How to copy Spotify in 30min”, Recharging/Boosting your Agility”, “Create Leaders at Every Level”, “Dealing with Shifting Priorities using Lean/Kanban Flow, WIP Limits and Capacity Allocation”, ” AdvanScrum”, “Feature discovery through Design Thinking”, “M-Agile – Best practices for successful Mobile Agile”, “BDD from the Trenches”, “Was it Worth It? Measuring the Success of an Agility Project in Business Terms”, “Fearless Change – Myths and Patterns of Organizational Change”. Web site: http://www.agileisrael2016.com/ Location for the Agile Israel conference: Tel Aviv, Israel
Categories: Communities

Links for 2016-05-29 [del.icio.us]

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:


advertisement:

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 InfoQ.com, 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


advertisement:

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 [del.icio.us]

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

From Divided to United — Aligning Technical and Business Teams

Learn how to unite around priorities, dependencies, and metrics, aligning technical and business teams. Discover how LeanKit created unity in our teams.

The post From Divided to United — Aligning Technical and Business Teams appeared first on Blog | LeanKit.

Categories: Companies

Shu Ha Ri: An Agile Adoption Pattern

BigVisible Solutions :: An Agile Company - Thu, 05/26/2016 - 19:45

 An Agile Adoption Pattern?Shu Ha Ri is something I was introduced to a few years ago and at first it seemed a bit of a stretch for me to apply it as an agile adoption pattern or to even just the idea of learning something new. Fast forward to today and I find that the distinctions of the levels are useful guides (not black and white rules) to help influence how to approach learning any new skill, including agile. This is certainly not a new topic and also not one without some controversy either.

What is Shu Ha Ri?

Shu Ha Ri is used to describe the progression of training or learning. It is a Japanese martial art concept that is used to describe the stages of learning to mastery. In recent years, it has been abstracted and applied to the cycle of learning in general. Since there tends to be a lot of learning that happens in agile, it’s very useful here as well. People like Martin Fowler, Alistair Cockburn, and many others have written about the use and application of Shu Ha Ri in agile environments.

Akido master teacher Endo Seishiro summarizes as follows:

“It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forbearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.” (Wikipedia. 17 Sept 2012.)

In a context relevant to agile adoption patterns, Martin Fowler defines Shu Ha Ri as follows:

Shu – In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
Ha – At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
Ri – Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

How Can I Use It as an Agile Adoption Pattern?

Instead of thinking right off the bat that your situation is unique and different and that you must find some custom solution, first ensure you have mastered the basics of the thing you are trying to do. Essentially, start simple with the basics and do those well first.

A simple, but useful example: A co-located team has a daily standup that usually runs 35+ minutes and they are convinced that they need to have standups less frequently so that members of the team can just “do their work.” Here’s how the Shu Ha Ri pregression can help.

Shu: The team would change their stand up to follow the 3 question rule, where each person provides updates only on what they did yesterday, what they plan to do today, and if there are any blocking issues. Once the team has deliberately followed this practice and exhibited a level of proficiency with it they are highly likely to have seen marked improvements in the duration of the standup as well as the quality of it.

Ha: The team is now very happy with the improvements they have made and are encouraged to make it better. So, they start to loosen the language around answering the 3 questions and add a 4th statement of “I could use help with x today” where it is appropriate. This change starts to yield improvements in how the team collaborates on their stories which helps them have fewer spillover stories. This continues for some time and the team continues experiments with various questions to augment or illuminate their current challenges.

Ri: The team has moved away from the mechanistic structure of any deliberate questions to answer and their standup is more like a flow of information that everyone finds useful. It is quick, concise, impactful, and adapts easily to the situation the team is facing.

Why the progression?

There’s a pattern and flow to the standup that “Shu” established. That pattern became an unspoken cadence or muscle memory that continues to drive how the team does their stand ups. That rhythm established for them the behaviors of being brief, concise, and to have follow-up conversations after the stand up. The questions and discussion changed over time, but the cadence and flow remain.

In the example of the team with the troubled standup, if they only ever focus on the mechanics (the 3 questions), they would never move beyond Shu and would therefore not continue improving. If they had just start experimenting with different questions and borrowing from other ideas, practices or disciplines (Ri), they would have never established their cadence. Without the cadence, their standups likely would not have become shorter in duration and they probably would have moved to having them less frequently.

Why are these distinctions useful?

I think one of the key tricks to this is figuring out the intersection of this line of thinking with real world situations. I don’t see the application of this as black and white at all. In fact, it is extremely gray, as it isn’t universally applicable, but I do believe it can be a great place to start your thinking.  I know when I am coaching and starting to work with a new agile team, I usually start with the looking at the basics to see how well represented they are in the teams process. I worked with an agile team that excelled at delivery and everyone was happy with the pace they were moving at. Upon further inspection, their two-week iterations were really a single 6-week iteration because all their stories would start in the first iteration then cascade across the remaining two.  Needless to say, we began a “Back to Basics” approach to work to get that and other things functioning better.

To me, the idea of Shu Ha Ri provides thinking tools, a language and a frame of reference to understand how to approach learning a new skill. When you are first learning something, variety of ideas isn’t usually the most helpful place to start. Once you get the basics down move on to experimenting and looking to integrate new thoughts or ideas. Your experiments will lead you to new paths and eventually you’ll move beyond the specific practices and evolve your own way of doing things.

Where do you think Shu Ha Ri could be useful in your organization or your team? Comment below to let us know!

 

Like this? You’ll love Agile Eats

Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!

The post Shu Ha Ri: An Agile Adoption Pattern appeared first on SolutionsIQ.

Categories: Companies

Targetprocess v.3.8.8: Custom Fields ordering in entity views, Text widget for Dashboards, minor design changes, bug fixes

TargetProcess - Edge of Chaos Blog - Thu, 05/26/2016 - 13:34
Custom Fields ordering in entity views

Do you use a lot of custom fields? Now you can change the order in which they are displayed! Place the most important Custom Fields at the top of the list, or group them by category to make your views more readable and adaptable to your needs.

For example, let's say you have the following list of Custom fields for a Project:

19-May-16 16-41-14

Which displays like this in a Project view:

19-May-16 16-46-10

You might decide you want to see all budget fields first. To do this, open the Custom Fields menu in Settings, hover the mouse over the corresponding field, and pull it into the position you want to see it on the view:

19-May-16 16-47-54

Now, budgets will be displayed first:

19-May-16 16-49-37

Dashboard widget: Text

A new text widget has been added to the widgets on Dashboard. Now, you can easily write up important details about current Project status and attach this information to your Dashboard.

20-May-16 12-17-00

Minor design changes

We've redesigned the progress bar and made general improvements to optimize:

  • card hover
  • cards selection
  • display of active entities
  • entity deletion
  • background highlighting
  • system performance 
Fixed Bugs:
  • Fixed image copy/paste duplication in Description
  • Fixed issue with password restore for inactive users
  • Fixed an issue with TFS Plugin not working with Visual Studio 2015
  • Fixed support for HTTP byte range request in tpondemand
  • Fixed the "Follow Activity" widget
Categories: Companies

7 Agile Practices You Can Apply in a Controlled Environment

Xebia Blog - Thu, 05/26/2016 - 12:25
So your teams want to do Agile, perhaps have even started doing so. Now your project managers run around wondering what story points are and why any number of people seem to be attributing hours to their project code. So the question is: what can you adopt easily without turning the Governance of your organisation
Categories: Companies

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

Office Exercise Roulette

Growing Agile - Thu, 05/26/2016 - 10:08
This week we instituted Office Exercise Roulette
Categories: Companies

Knowledge Sharing


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