Skip to content

Companies

How to Boost Collaboration with Targeted Notifications

In today’s busy workplace, how do you make sure you’re collaborating effectively? Team emails and all-hands meetings — while good at keeping everyone up to speed — can be inefficient for managing day-to-day communications. To cut down on the status update clutter and inject more meaning into ongoing conversations, try using targeted notifications directed to those who […]

The post How to Boost Collaboration with Targeted Notifications appeared first on Blog | LeanKit.

Categories: Companies

Agile for Project Managers

Rally Agile Blog - Mon, 08/11/2014 - 17:17
Agile: Where It’s At

Did you know that according to job board indeed.com, openings for project managers (PMs) with Agile experience have grown more than 2,500% since 2005?

As more companies seek greater value from technology projects by making the switch from waterfall to Agile, it’s imperative that project managers maximize their value, too, by understanding their role in Agile projects and keeping their skills sharp. A recent global survey from PricewaterhouseCoopers (PwC) showed that 34% of PMs now use Agile methods, and a majority of PMs (62%) are certified Agile practitioners.

“Not only have organisations raised the bar in order to stay competitive in the turbulent business environment, but PM standards have also significantly increased … more practitioners are becoming certified in PM with an increased adaptation of Agile PM and EVM.” (PwC)

Get Accredited

Earning your credentials as a Project Management Institute Agile Certified Practitioner (PMI-ACP) is a great way to take your skills and versatility to the next level. If you’re preparing to take the PMI-ACP exam, Agile University has got just the training you need to make you ready to test with flying colors.

What You’ll Learn

Come spend a few days in beautiful Boulder, Colorado, to up your game on topics like:

  • The Agile Manifesto
  • Lean Basics
  • Kanban Design and Value Stream Mapping
  • Communication and Information
  • Planning, Estimating and Adjustment Practices
  • Iterative Risk Management
  • Facilitation Techniques and Conflict Resolution
Who Should Come

If you want to acquire a thorough understanding of Agile / Lean principles and practices, invest in high-quality professional training, and pass the PMI-ACP exam on the first try, this is the course for you.

Sign On Up

Join us November 4-5, 2014. Find out more and register, here.

Can’t make this one? Check our course calendar to see upcoming dates for this and other great classes!

Rally Software
Categories: Companies

The AngularJS Promise DSL

Xebia Blog - Mon, 08/11/2014 - 11:21

As promised in my previous post, I just pushed the first version of our "Angular Promise DSL" to Github. It extends AngularJS's $q promises with a number of helpful methods to create cleaner applications.

The project is a V1, it may be a bit rough around the edges in terms of practical applicability and documentation, but that's why it's open source now.

The repository is at https://github.com/fwielstra/ngPromiseDsl and licensed as MIT. It's the first OS project I've created, so bear with me. I am accepting pull requests and issues, of course.

Questions? Ask them on the issues page, ask me via Twitter (@frwielstra) or send me an e-mail. I'd offer you to come by my office too... if I had one.

Categories: Companies

New Sprint.ly Update: Item Detail Modal

sprint.ly - scrum software - Sun, 08/10/2014 - 23:57

Today we released a great new update for quickly viewing an item’s detail and history.  We developed a modal for the item detail view. Click on an item’s title and a child window opens up with detailed information for that particular item. You can review, comment and add attachments to tickets without losing your place on the main page. Losing context while reviewing items is a piece of feedback we’ve heard often.

I hope this update helps you use Sprint.ly more efficiently and please keep the feedback coming. We have much more up our (tattooed) sleeves. Stay tuned!

Categories: Companies

Agile Conference Revolution

TargetProcess - Edge of Chaos Blog - Sun, 08/10/2014 - 22:16

This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.

I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.

How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?

Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?

There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.

SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.

SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.

So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.

I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.

All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:

  1. Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
  2. Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
  3. There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
  4. Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
  5. 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.

In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.

The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?

BtvFR0oCAAAZXtN

I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.

“Pirates are bold not safe” — These guys are doing something good

Categories: Companies

Myths I Do Not Believe In

NetObjectives - Sun, 08/10/2014 - 14:19
One of my frustrations in the industry is that so many people continue to propagate ideas for which I do not to believe to be true.  Much of the time there is vast evidence to the contrary, but these ideas are rarely talked about on discussion groups.  I’ve even seen their discussion to be discouraged by many. I am sure people’s intentions are noble, but it is poor science to not examine one’s...

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

Project Management with Kanban (Part 3) - Forecasting

In part 3 of our look at Project Management with Kanban, we consider project planning using probabilistic forecasting. Kanban originally shocked the Agile community in 2008 as it became known for not using several practices agilists hold dear: no time-boxed iterations; no prioritization; and perhaps most shocking of all, no estimation!!! So how do you plan a project with a method that doesn't use estimates? The answer is that you use historical data or a model of expected capability to build a probabilistic forecast of the project outcome. What follows is a short discussion of one simple and common model for forecasting a project dellivery schedule...

read more

Categories: Companies

Sprint.ly Welcomes Justin Jackson to the Team!

sprint.ly - scrum software - Fri, 08/08/2014 - 22:00

I’m super-excited to introduce Justin Jackson to everybody today. Justin joined us just this week and will be running Sprint.ly’s product marketing. Read on below to learn more about Justin.

Howdy! I’m Justin Jackson and I’m thrilled to be joining the Sprint.ly marketing team.

I’ve spent the past 6 years working in product management and marketing for a SaaS based web application. In 2012 I started using Sprint.ly to manage my team and it radically improved our development process. Every member of our business could see what was being worked on, and what was finished: for the first time ever, everything was transparent. I’ve been a huge believer in Sprint.ly ever since.

When I started my podcast Sprint.ly stepped forward to become my first sponsor. As an active member of the product community, I kept seeing Sprint.ly’s name pop up as a sponsor for other things as well: Rails Rumble, Django Dash, etc… It’s clear that the team is passionate about beautiful products, and the people that make them.

As a product person, Sprint.ly was always one of my favorite products. They seemed to embody everything I liked: amazing design, well though-out user-experience, and commitment to serving all corners of an organization. For me, it’s a dream to be working side-by-side with these amazing folks.

Categories: Companies

Su the Wizard – a short walk with a “Scarce Resource”

BigVisible Solutions :: An Agile Company - Fri, 08/08/2014 - 17:22

    You know Su. Su’s the person everyone needs all the time.  As you scale Agile, or any other development approach, you face the age old challenge of optimizing the return from high value scarce “resources”. The variety of well-intended, logical, and marginally unrealistic solutions you can try range from Lean based allocation models […]

The post Su the Wizard – a short walk with a “Scarce Resource” appeared first on BigVisible Solutions.

Categories: Companies

Extending AngularJS services with the Decorate method

Xebia Blog - Fri, 08/08/2014 - 13:00

Many large Angular applications tend to see a lot of repetition - same API endpoint, same method of dealing with and transforming data, etcetera. One technique you can use to at least alleviate that is using AngularJS's decorate method, which allows you to extend, adjust or even fully replace any existing service.

As you'll see in this post, using this allows you to modify and extend the framework you build your app in, which will lead to a cleaner, more legible codebase, written in a more functional style (the what, not the how).

Update 11/8: The follow-up is now live, along with the GitHub repository.

A feature not often used when developing AngularJS applications is the $provide service, which is the primary service used to register components with the $injector. More commonly, a developer would use methods like $provide.service() or $provide.factory to do so, but those are merely utility methods defined in the $provide service and exposed via angular.module().

The main reasons to use $provide over the service() and factory() methods is to configure the service before it's instantiated, for example. While there may be more advanced use-cases for using $provide, I haven't yet encountered them while developing regular applications and I'm sure they won't occur often.

One of the methods listed at the very bottom of the $provide documentation is the decorate() method. It doesn't look like much (it's at the bottom, after all), but its documentation hints that it's very powerful:

"A service decorator intercepts the creation of a service, allowing it to override or modify the behaviour of the service. The object returned by the decorator may be the original service, or a new service object which replaces or wraps and delegates to the original service."

Nothing to add there. You can use decorate() to change, add to, or completely replace the behaviour of services without having to edit its code. This can be done on any code not your own - core AngularJS services, but also third-party libraries. It's the equivalent of overriding methods in OO languages or monkey-patching in the more dynamic languages.

“Isn’t that evil?”, I hear you ask. As with every programming-related question, the only correct answer is: it depends. I’m going to give a few practical examples of when I believe using decorate() is appropriate. In a future blog post, I'll expand on this example, showing how relatively simple code can positively influence your entire application architecture.

Here’s a practical example, a neat follow-up on my previous blog about angular promises: decorating $q to add methods to the promise object. The promise API itself defines only one method: then(). $q adds a few simple methods to that like catch() and finally(), but for your own application you can add a few more.

If you’ve been working with promises for a little while in your AngularJS application, you’ve probably noticed some operations are pretty common; assigning the promise result to the scope (or any object), logging the result in the console, or calling some other method. Using decorate(), we can add methods to the promise object to simplify those. Here's a bit of code from my previous post; we'll add a method to $q to remove the need for a callback:

CustomerService.getCustomer(currentCustomer)
 .then(CartService.getCart)
 .then(function(cart) {
   $scope.cart = cart;
 })
 .catch($log.error);

First, we’ll need to do some boilerplate: we create a function that adds our methods to the promise object, and then we replace all the default promise methods. Note that the decorating function will also apply itself to the given promise.then method again, so that our customisations aren’t lost further down a promise chain:

angular.module('ngPromiseDsl', [])
  .config(function ($provide) {
    $provide.decorator('$q', function ($delegate, $location) {

      // decorating method

      function decoratePromise(promise) {
        var then = promise.then;

        // Overwrite promise.then. Note that $q's custom methods (.catch and .finally) are implemented by using .then themselves, so they're covered too.

        promise.then = function (thenFn, errFn, notifyFn) {
          return decoratePromise(then(thenFn, errFn, notifyFn));
        };

        return promise;
      }

      // wrap and overwrite $q's deferred object methods

      var defer = $delegate.defer,
        when = $delegate.when,
        reject = $delegate.reject,
        all = $delegate.all;

      $delegate.defer = function () {
        var deferred = defer();
        decoratePromise(deferred.promise);
        return deferred;
      };

      $delegate.when = function () {
        return decoratePromise(when.apply(this, arguments));
      };

      $delegate.reject = function () {
        return decoratePromise(reject.apply(this, arguments));
      };

      $delegate.all = function () {
        return decoratePromise(all.apply(this, arguments));
      };

      return $delegate;

    });
  });

With that boilerplate in place, we can now start adding methods. As I mentioned earlier, one of the most common uses of a then() function is to set the result onto the scope (or some other object). This is a fairly trivial operation, and it’s pretty straightforward to add it to the promise object using our decorator, too:

function decoratePromise(promise) {
  var then = promise.then;

  promise.then = function (thenFn, errFn, notifyFn) {
    return decoratePromise(then(thenFn, errFn, notifyFn));
  };

  // assigns the value given to .then on promise resolution to the given object under the given varName
  promise.thenSet = function (obj, varName) {
    return promise.then(function (value) {
      obj[varName] = value;
      return value;
    });
  };

  return promise;
}

That’s all. Put this .config block in your application's module definition, or create a new module and add a dependency to it, and you can use it throughout your application. Here's the same piece of code, now with our new thenSet method:

CustomerService.getCustomer(currentCustomer)
  .then(CartService.getCart)
  .thenSet($scope, 'cart')
  .catch($log.error);

This particular example can be extended in a multitude ways to add useful utilities to promises. In my current project we’ve added a number of methods to the promise object, which allows us to reduce the number of callback definitions in our controllers and thus create cleaner, more legible code.

 

Replacing custom callbacks with named methods allows for a more functional programming style, and allows readers to read and write code as a list of “whats”, instead of “hows” - and it's also fully asynchronous.

Extending $q is just the start though: Every angular service can be extended for various purposes - add performance monitoring and logging to $http, set common prefixes or fixed properties on $resource urls or template paths, you name it. Leave a remark in the comments about how you've used decorate() to create a better application.

Stay tuned for an upcoming post where I release a small open source project that extends angular’s promise objects with a number of helpful methods to perform common tasks.

Further reading, resources, helpful links:

Categories: Companies

A Valuable Sprint Review (a.k.a. Demo): How To

Xebia Blog - Thu, 08/07/2014 - 11:05

A valuable Sprint Review (from now on in this blog referred to as Demo) can be built in three steps. It starts during the Sprint planning session with agreeing on and understanding the user stories on the Sprint backlog. Then, during the Sprint, the team constantly exchanges ideas and results of the realisation of the Story. Finally, during the demo itself, the Product Owner and the rest of the team demo the stories to the stakeholders to display the value delivered and open up for feedback.

Planning for a good demo

During the planning session, it is imperative that the Product Owner and the rest of the team understand the stories that will be picked up. This sounds obvious, but it happens often that this is not the case. Stories might be too technical so the Product Owner is disconnected or stories are so high level that it is hard to determine what needs to be done.

Make sure stories are formulated from the perspective of an end-user of the functionality that will be delivered. This could be an actual user, a system that picks up whatever result is created or any other manifestation of who or what will use the result of the story.

Also take care of getting the acceptance criteria clear. This way it will be clear to developers what to build, to testers what to test for and designers what to design. It will help the Product Owner to have a better idea what is in and what might have to be defined in a new/other user story.

It is important that everyone understands the context in which the story ‘lives’. What part of the system is touched (end-to-end is preferred but not always possible), which parties are affected by the change, what prerequisites are needed, etc.

Building for a great demo

When during the creation of the value of each story the whole team is in constant contact about intermediate results and decisions taken, everyone will be able to add to the value and be aware of what the result of the story will be. It is very important that the whole team is including the Product Owner. When the PO sees the intermediate results, she or he can already create an image of what the result will be like. Also, the PO can contact stakeholders that might have an opinion of what is created and, when needed, adjust the end result to match expectations.

Delivering an valuable demo

In the demo, the Product Owner should present to the stakeholders the value of each user story that has been delivered. So, per story, explain what has changed from the perspective of the end-user and have the rest of the team show this. Also, when stories are not done, explain which (sub-)functionality is not yet finished. Make sure to ask for feedback from the end-user or other stakeholders on what is demonstrated.

Conclusion

The value of the demo depends largely on the cooperation of the entire team. When the Product Owner and the rest of the team work together on understanding what will be delivered and help each other to get the most value from each story delivered the demo will be focused, valuable and fun.

Categories: Companies

Scrumban

Xebia Blog - Wed, 08/06/2014 - 20:19

Scrum has become THE revolution in the world of software development. The main philosophy behind scrum is accepting that a problem cannot be fully understood or defined at start; scrum has the focus on maximizing the team's ability to deliver quickly and respond to emerging requirements. It came as truly refreshing in the time when projects were ruled by procedure and MS-project planning. Because of scrum:

  1. Projects can deliver what the customer needs, not just what he thought he wanted.
  2. Teams are efficient. They work as a unit to reach a common goal.
  3. We have better project roles (like a product owner and scrum master), ceremonies (like daily stand-ups, grooming) and a scrumboard.

But the central question is: "are we there yet"? And the answer is: "No!". We can optimize scrum by mixing it with kanban, which leads to scrumban.

A kanban introduction for scrummers

Instead of scrum, which is a software development framework in the widest sense of the term, kanban is a method. It, or instance, does not define ceremonies and project roles. There are two main principles in kanban I would like to highlight:

  1. Each column on the kanban board represents a step in the workflow. So, instead of the lanes 'todo', 'inprogress' and 'done' like in scrum, you have 'defining', 'developing', 'testing' and 'deploying'. That is a more full-stack view; a task has a wider lifecycle. This concept is also called 'from concept to cash'; from user research and strategic planning to data center operations and product support.
  2. Another principle of Kanban is that it limits WIP (work in progress). An example of a WIP limit is limiting the number of cards allowed in each column. The advantage is that it reveals bottlenecks dynamically. Because of the WIP, Kanban is a pull mechanism. For instance, a tester can only pickup a next work item if there are items available in de done-column of development-lane and when the WIP limit of the test-lane isn't exceeded.

After all kanban is incredibly simple, but at the same time incredibly powerful.

What's wrong with scrum?

  1. The reason why we went to scrum is because we did not want the waterfall approach anymore. But, in fact each sprint in scrum has become a mini waterfall. In each sprint teams plan, try to design, develop and test. At the end the product owner reviews the completed work and decides which of the stories are shippable and ready for production. Those sprints can result in a staccato flow, which can be exhausted. With kanban we can make sprints more agile and the goal is to have a more continuous flow. In comparison with how to run a marathon? You don't make sprints of 200 meters, but rather with a constant rate.
  2. Scrum is a push mechanism and therefore 'pushes' the quality out of your product. When a sprint backlog is defined, the team is asked for a commitment. Whatever happened, a team must satisfy its commitment and at the end of the sprint the product owner must say 'decharge', else the team has failed. No team wants to publicly fail, so most of the time, at the end of the sprint, teams take shortcuts to satisfy the deadline. Those shortcuts are killing for quality! Asking for commitment is like not trusting the intrinsic motivation of the team. The correct commitment is visible during each standup. During a standup team members have to tell each other what they've done the day before. If they are working too long on a story, another team member will rebel. That is the real commitment.
  3. One of the reasons why we do scrum is that it is better to start immediately instead of doing an estimation and a feasibility study upfront, because almost always after the study is completed, the project will be executed. The estimation at the start is not reliable and the feasibility study is just a waste of time. Isn't that the same mistake we make with scrum with the grooming and ready sessions that causes a lot of overhead? The first overhead during grooming is that we give an estimation with relative precision. It is in a developer's nature to argue about the story points; is it 3, 5, 8 or maybe 1 points? And that is a waste. You should only talk about the story sizes large, medium or small. Making a more precise estimation is just a waste of time, because there are too many external factors. Second, with the grooming we do a mini feasibility study. With a team we will think about a direction of the solution, which is fine. But most of the time it takes two or three sprints before it is realized in the sprint. And with all the weekends of beer in between we've already forgot the solutions. So one smart guy says: 'yes, lets document it', but that is an inefficient way for the real problem: there is too much time between the grooming and the realization.

Scrumban: the board of kanban

Untitled

A scrumban board

The first column in a scrumban board is reserved for the backlog, where stories are ordered by their respective priority. There are several rules for the kanban backlog:

  1. It is the product owner's responsibility to fill this lane with stories, and keep it steadily supplied. The product owner must avoid creating or analyzing too many stories, because this is a waste and it corrupts with the Just-In-Time principle of scrumban. Therefore the scrumban board has a WIP-limit of 5 backlog stories.
  2. Assure the necessary level of analysis before starting development. Each story must be analyzed with a minimum effort. That should be done in the Weekly Time Box (WTB), which will be discussed later on.
  3. The backlog should be event-driven with an order point.
  4. Prioritization-on-demand. The ideal work planning process should always provide the team with best things to work on next, no more and no less.

Next to the backlog-column is the tasking-column, in which there should always be at least one story that is tasked (a minimum WIP-limit). If this isn't the case the team will task after the standup to satisfy this condition. A story is picked up from the backlog and is tasked by the team. Tip: put the tasked cards at the back of the story cards. The next columns are the realization columns. Each team is free to add, remove or change necessary columns so it suits the business. In the realization columns there should be a maximum number of stories that are worked on. If the maximum limit has not been reached, a story can be pulled from the tasking column and unfolded on the 'to implement' lane. Now the team can work on the tasks of the story. Each task that is implemented can be moved to the 'ready' lane. If all of the tasks are done for a story, the story can be moved to the next lane. When the story and tasks are ready, the cards can be moved to the right bottom of the board, so there is a new horizontal lane available for the next story.

Scrumban: the ceremonies of scrum

With scrumban we only have two types of meetings: the daily standup and the weekly timeblock. The Weeky Timeblock is a recurring meeting used for multiple purposes. It should be set up in the middle of the week. The big advantage of the weekly timeblock is that developers are distracted from their work only once a week (instead of the various of meetings with scrum).

The Weekly Timeblock contains three parts. First there is a demo of the work done. Second, there is a retrospective on the development process of the last week. Third, the team should have a preview of upcoming workitems. The team try to understand the intent of each item and provide feedback. The only size-indication a team has to make is if the story is small, medium or large. Avoid using poker cards/story points, which are too fine-grained and are to vague.

Conclusion

Scrumban is a mix of the scrum ceremonies and the kanban method. With scrumban we

  1. Introduce the weekly timeblock (WTB). The weekly timeblock should be around 4 hours and there are no more meetings
  2. Have a wider lifecycle of a story: 'from concept to cash'.
  3. Change the scrumboard to  company flows and avoid the push principle of a sprint but using a pull mechanism.
Categories: Companies

Kanban should be the default choice for DevOps teams

Xebia Blog - Wed, 08/06/2014 - 15:59

We had a successful workshop on DevOpsDays 2014. Our main point was that Kanban should be the default choice for DevOps teams. The presentation can be downloaded here.

DevOpsDays 2014 was a success

On the 19th, 20th & 21st of June 2014 the second edition of DevOpsDays Amsterdam was held in Pakhuis De Zwijger in Amsterdam. This year I was asked to teach a course there on Kanban for DevOps. At the 2013 edition I also gave a presentation about this subject and it was nice to be invited back to this great event.

With the Open Source mindset in mind I teamed up with Maarten Hoppen en Bas van Oudenaarde. Our message: Kanban should be the default choice for DevOps teams. 

The response to this workshop was very positive and because we received a lot of great feedback I thought I’d share the slide deck. The presentation assumes you are working in an environment where DevOps might work or is already being implemented. 

Main points of the presentation

DevOps is about Culture, Automation, Measurement and Sharing (CAMS). These four values require a way of working that looks past existing processes, handovers and role descriptions. 

The Kanban Method is about looking at your organization in a different way. From a point of:

  • Sustainability: by shaping demand and limiting Work in Progress
  • Service-Orientation: by creating an SLA based on past results and data
  • Survivability: create an improvement mindset in the organization to respond to rapidly changing environments

The three different ways the Kanban Method makes you look at your organization makes it an extremely powerful solution for DevOps.

If you are interested to learn more about the workshop, check out the slides here:

http://www.slideshare.net/jsonnevelt/kanban-bootcamp-devopsdays-2014

Categories: Companies

Hot news for GitHub lovers

tinyPM Team Blog - Wed, 08/06/2014 - 14:35

Finally happened! Over 6 million users & over 14 million repositories of GitHub integrated with tinyPM? It’s more than possible now. Imagine product management integrated with the largest code host on the planet. All in one – from vision to implementation. You absolutely have to check it out!

462550595(1)

Why should you try it out?

Integration with GitHub allows you and your team to link commits in GitHub with user stories in tinyPM. This carries your team through the latest development work and the whole history of commits for each story. When you push your changes to GitHub, it will forward your commit to tinyPM offhand. By including a special text in the commit message you can indicate whether this commit is related to a user story or task in tinyPM.

Stay up to date and tie your commits easily to user stories

To enable GitHub integration with tinyPM just activate tinyPM Service in your GitHub repository:

  • In GitHub open a repo you manage and click on Settings
  • Select Webhooks & Services
  • Click Add service and select tinyPM from the available services
  • Add your URL – copy it from the “Application Settings” page in your tinyPM

github-setup

github-url

 

github-setup_service

 

Linking commits to user stories

Simply include a user story #id in the commit message #512 and the commit will show up on this story card.

Example commit message:

task_1

Linking commits to tasks

To add a reference link to a commit, just include a label like task:123 in the commit message.

Example commit message:

task_3
Move tasks via commit messages

Add a message like completed task:123 and tinyPM will update the task status when you push your commit.

Example commit messages:

task_2

Good day & good luck! :-)

 

Categories: Companies

More, better, faster… CSV import/export now with epics!

Pivotal Tracker Blog - Tue, 08/05/2014 - 22:29

Though your stories look gorgeous in Tracker, exporting to CSV is handy way to make a backup, share a different view of particular stories, do bulk updates, make a report or create a project template.

To make getting stories into and out of Tracker easier for you, we’ve improved several aspects of CSV import and export.

Epics

ExportEpics
You can now export and import your epics. When the ‘Type’ column contains ‘epic’, that indicates that the row is an epic. Just like stories, if the id doesn’t match an existing story in the project you’re importing into, a new epic will be created. However, if there is a matching epic, it will be updated with any changes you’ve made in that row.EpicinCSV

Faster upload with a much higher story limit

Previously, you could only import 100 stories at a time, due to performance constraints. Now, not only is import performance improved, you can import 500 stories into your projects at once.

Helpful error handling

CSV import can be tricky if your Point Scale or other Project Settings don’t match in a source and destination project. Or perhaps you accidentally saved in a different format than CSV or there’s a typo in some editing. We admit it, our old error messages were pretty obtuse. But now we step you through the problem and remedy, so you can get past glitches far more easily. As well as more detail on the problem, the row-by-row breakdown helps you find the rows you need to correct.ImportErrors

CSV Options in the beta

Just as the same as in the original version of Tracker, you can click or shift+click the selection boxes to the right of the story title, to select stories, However in the beta, as soon as one or more story selection boxes are clicked, options for just selected stories appear at the top left.

To select all the stories in a panel, click the cog menu at the very bottom of that panel.

All the options, including those for CSV, that you’d find in the Project menu in original Tracker, can now be found under the cog menu at the top right of the sidebar in any project.

SelectedInBeta

For more on importing and exporting your stories and epics, please see the Import & Export section of the FAQ.

Also feel free to get in touch via email and if you don’t already, please follow us on Twitter for updates.

The post More, better, faster… CSV import/export now with epics! appeared first on Pivotal Tracker.

Categories: Companies

Agile & UX: What’s wrong with working one sprint ahead?

Growing Agile - Tue, 08/05/2014 - 14:14

Let me start this post by saying I am not a UX expert in anyway, however we have been chatting to Flow Interactive recently about how agile and UX fit together. There seems to be a common pattern that UX runs one sprint ahead. Flow have had great success doing this, but when we heard about the idea it sounded a little mini-waterfallish to us. This blog post is an attempt to explain that gut feeling, and to mention some ideas of how this might work different, all shameless stolen from a nice chat with Adrian Howard  Whats wrong with working one sprint ahead?

Working one sprint ahead or behind sounds familiar. Testing used to work one sprint behind, until they found ways to automate testing, test earlier and test smaller chunks. Business Analysts used to (and maybe some still do) work one sprint ahead writing specs and designing solutions. I’d like to think most now see this isn’t optimal and can in fact be done in the same sprint if you learn how to slice work smaller. So hearing about UX working one sprint ahead, just sounds like a discipline still finding a way to work in smaller pieces.

 Whats wrong with working one sprint ahead?

What’s wrong with working one sprint ahead?

The main issue with this is one of focus. If the UX designers work one sprint ahead of the rest of the team, then the UX designers and the team actually never work on the same stuff at the same time. This means they are never focused on the same thing. When this is true a couple of things can happen:

  1. It doesn’t make sense to have the same standup meeting because you aren’t working on the same stuff.
  2. It’s harder to help each other out because you are focused on finishing different stuff
  3. The people working ahead consider their deliverable some interim artefact, not working software, so there is a handover of both knowledge and responsibility.
  4. People don’t see themselves as part of the same team, so you end up having a UX team and a dev team. This inhibits collaboration and communication.
  5. The people working behind aren’t involved in the decision making that happened without them and as a result they don’t understand the reasons for certain design choices, this often leads to assumptions, and rework.
  6. Okay, but we can’t start coding before we know what go build?

I’m not advocating writing code before an UX work has taken place. I’m saying the whole team should be involved in that work. Obviously the UX designer(s) take the lead here, but everyone on the team needs to see users use their product and understand the user journey map. If the rest of the team is busy with other deliverables this can’t happen.

So how can we do this?

I remember when business analysts ran one sprint ahead getting the requirements and specs ready for the sprint. I’ve solved this by having more backlog grooming or refinement sessions with the whole team, and yes that does happen a sprint ahead. i.e. in sprint 1 we refine stories for sprint 2. However we do it but allowing a percentage of time in the current sprint to be spent preparing for future sprints. This means everyone can get involved. The analyst might take point and run the session, but the whole team understands the requirements and decisions made before the sprint starts.

I think UX can be tackled in the same way. In each sprint the whole team should set aside time to look at UX designs for the next sprint, as well as usability testing whatever has been completed. Adrian mentioned that a great way to do this is to have users available every week for a few hours. The team can decide how best to make use of the users the day before, either run a usability test, or interview them about a new idea, or show them paper prototypes. This can significantly reduce the time delays in recruiting users when you need them.

Why is this better?

Like with agile testing, if testers are involved right from the beginning they can ask “how can we test that” early and often prevent bugs. Similarly having developers involved with UX design they might advise when something is difficult to build. They will also understand which parts of the design are crucial because of user feedback, and are then much more likely to implement a solution that adheres to these designs. I believe this will result in less rework, and better designed products, as well as more collaborative teams.

Categories: Companies

Insights at Agile 2014, Part III: Lean-Agile Development, 3rd Generation Agile

NetObjectives - Tue, 08/05/2014 - 07:57
The thinking that got us here won’t get us where we need to be. - Einstein This Blog Post in a Nutshell This blog is a culmination of some ideas that started at Agile 2013 and was presented in an open jam session in Agile 2014. Product developers should adopt a Lean mindset.They can then look at their situation, ask a few questions, and decide on the particulars of the development process...

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

Project Management with Kanban (Part 2) - Sequencing Policies

In this second in my series of posts exploring project management with Kanban, I'd like to look at how we build a project schedule.

We prefer not to use the term "prioritization" with Kanban because prioritization isn't something done once or periodically leading to a prioritized list, instead prioritization is done dynamically each time an item is pulled through our kanban system. Prioritization isn't an activity in Kanban, it is a consequence of decisions made dynamically based on the risk profile of available work when a pull signal is generated in the kanban system.

read more

Categories: Companies

Agile 2014 – Stuck in Shu – Time to Change How to Teach Scrum

NetObjectives - Mon, 08/04/2014 - 07:55
It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. - Mark Twain  The problem ain't what people know. It's what people know that ain't so that's the problem. – Will Rogers  A man who carries a cat by the tail learns something he can learn in no other way. Mark Twain There are three kinds of men. The ones that learn by readin’. The few who learn...

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

Why Many of Us Blindly Follow a Community After Initial Success

NetObjectives - Mon, 08/04/2014 - 07:29
I had forgotten the second half of this amazing quote from R. Buckminster Fuller. Operating Manual for Spaceship Earth "I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way...

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