Stories in Pivotal Tracker have been given a serious upgrade. For the most part it’s all pretty self explanatory - the functionality you’re used to is all there, just in a format that’s more intuitive, user friendly and hopefully you’ll agree, more appealing. Our advice, play with it and then come back and read the rest of this post, especially if anything is confusing.

You’re back, so let’s continue!

One of the goals of Tracker has always been to make collaboration around your story backlog as easy as possible, so that your team spends less time managing your project and more of it actually building things. We think there’s room to make that not just easier, but more enjoyable, even fun! So to that end, great usability and user experience are major themes in our backlog for 2012, starting with this story redesign.

See below for all the highlights.

New Look and Feel

Like we said, stories look different, and are hopefully a lot easier to work with now. It's a complete redesign, with a color scheme that fits better with the rest of the Tracker UI, and that's intended to make the important information in a story stand out more - such as the story title, description, comments, code commits, and file attachments.

Besides visual appeal, we’re aiming to reduce clicks - for example, when creating a new story, it only takes one click to choose a story type or point estimate value. And, you can now start, finish, deliver, or accept/reject an expanded story with one click, with the familiar buttons.

Click to Copy ID and Story URL

We heard your feedback about having to scroll down in stories to find their IDs, to copy them to your commit messages (you are using the source commit integration, right?). So, we've moved the ID to the top of stories, and made it so that you can copy the ID to the clipboard with one click (on the ID button).

The same is true for the story URL, for when you need to send someone a link to the story. Just click the link button in the top left corner, and the story's full URL will be copied to the clipboard. Note - you’ll need Flash enabled in your browser for these to work. If you don’t have Flash, you’ll see the full URL on a separate line, so you can copy it the old way.

Less commonly used actions, including delete and view history, have been moved to the “More” menu, which is where we’ll be adding some other convenience actions soon.

File Attachments on Comments

One big change in this redesign is that files are now attached to stories as part of posting a comment, rather than as a separate list. This is because files are commonly uploaded and shared in the context of an on-going conversation, and it’s so much easier to refer to a file that’s actually part of that comment (e.g. “Here’s that icon”) rather than having to say “see the file named foo.gif at the bottom of the story”.

You can still drag and drop files from your desktop to stories, and entering an actual comment when adding files is optional - just drop your files on a story and close it.

View All Images and Comment Filtering

The truth is, thumbnails of mockups attached to a story can be indistinguishable from one another. Sometimes you just need to see them all full sized, on one page. Now, with just one click of the View All Images link above the Activity section, you can.

We’ve also made it easier to find what you need in a long-winded (all of it beautifully clear and vital) comment conversation - just use the filter dropdown menu at the top right of the Activity section to show just file attachments, just source commits, or all comments without commits.

Feedback

This redesign of stories is the first step in an on-going usability overhaul. We’ve got much more coming over the course of this year, but we’d like to incorporate your feedback at every step, so please let us know what you think so far, in the comments here or by email to tracker@pivotallabs.com.

We've got a major update of Pivotal Tracker planned for this weekend, which requires downtime while we run a fairly major database schema migration.

The update is planned for Saturday, Feb. 4, at 9:00 Pacific Standard Time (PST), or 17:00 UTC, and we expect it to take approximately one hour.

Apologies for the inconvenience, but we're hopeful that you'll like what we're rolling out!

For real time status updates, please follow @pivotaltracker on Twitter.

Introduction

Setting up Git can be intimidating, especially for those that are trying a version control system for the first time or moving from Subversion. It used to be the case that Git was a huge hassle to install and use on Windows. However, nowadays it's super easy to use Git on Windows either through Git Bash, if you're a fan of the command line, or if you prefer a graphical interface, through programs like TortoiseGit. Below we'll show you how to set everything up and connect it with Assembla.

Note: Below is a condensed version that doesnt show EVERY screenshot along the way. For the long version, click here.

Table of Contents

1. Download and Install Git for Windows
2. Download and Install TortoiseGit (Optional but recommended for first timers)
3. Generate SSH keys
4. Link SSH key with Assembla

Prerequisites

1. Assembla Git repository - sign up if you haven't already, it's totally free for standalone Git hosting.
2. A strong desire to install Git on Windows.
3. That's it, let's go!

1. Download and Install Git for Windows

To get things started, you'll need to download and install Git for Windows. You can download it here. If you're unsure of which one to choose, just go with the full installer. After downloading, run the installer.

 
If you have PuTTY/TortoiseSVN installed, you may see this screen, otherwise just ignore this. Regardless, use OpenSSH to make things easy. 
 

Download and Install TortoiseGit

This step is optional. If you are comfortable using the command line for interacting with Git, you do not need to install TortoiseGit.

Next up, let's download and install TortoiseGit.
 

We'll need to configure TortoiseGit - to do this, right click anywhere on your Desktop, select "TortoiseGit" and then "Settings."


Find "Git" and then click on "Config" from the menu on the left. Then fill in your Name and Email, making sure to use the same email that you used to sign up for Assembla.

Don't forget to click OK when you're done.
 


Great, now TortoiseGit is all set! Generate SSH keys

There's two ways to generate SSH keys:
  1. If you installed TortoiseGit, use the method directly below. 2. If you only installed Git on Windows and are not using TortiseGit, jump to the "Git Bash SSH Keys" section.

TortoiseGit SSH Keys

SSH creates a secure connection from your computer to Assembla, making sure that you are who you claim to be so that only authorized persons can commit to your repository. Assembla needs to know your public SSH key to make the secure connection, so let's fire up Puttygen to generate an SSH key pair.

Start -> Programs -> TortoiseGit -> Puttygen


In Puttygen, first click on the "Generate" button.


Next, you'll move your mouse around the big gray area under the progress bar to generate randomness for super security.


Once the key is generated, you should copy it onto your clipboard. You'll use this later to authenticate with Assembla.


Afterwards, choose a memorable password and confirm it. Don't forget your password!


Lastly, click on the "Save private key" button and save your private key somewhere you'll remember.

Git Bash SSH Keys If you did not install TortoiseGit, you're at the right place! If you did install TortoiseGit, follow the steps above and skip this section.

• Start up Git Bash: Start -> All Programs -> Git -> Git Bash
• On the command prompt, type in the following command substituting with the email you used to sign up for Assembla.
• When it asks you for the file, just hit Enter.
• Please note that you should definitely enter a passphrase; when you type, nothing will show up. This is normal, don't worry about it.

ssh-keygen -t rsa -C "me@email.com"

Use Notepad to open up the .ssh/id_rsa.pub file you just generated and copy the all of the contents of that file.

Link Your SSH key with Assembla Open up your Assembla profile which is where you'll paste the public key you just copied from the previous step. 
 
Click "Add Key" after you've pasted the key into the box. You should see something like the following picture below. If so, congratulations, you're done with this section!
  Create Something! Now the fun begins! Click here to learn how to clone your git repository, add files, commit, and push.  
Stuck? Need help? If you encounter difficulty with any of this, don't hesitate to contact Assembla support.

Early this morning, we started experiencing extremely slow response times on our LeanKit websites and e-mails. After determining that our servers and system were themselves working properly, we isolated the issue to our domain registrar GoDaddy. Hackers had re-routed some of our web addresses to a site protesting proposed intellectual property legislation called SOPA. We [...]

For years, companies and teams have focused on adopting agile at the team level. Team members and ScrumMasters work to improve their sprint planning and collaboration techniques—the things they do on a day-to-day basis to execute work. Product owners, ScrumMasters, and team members also focus heavily on delivering projects—learning how to use a product backlog, do release planning, and deliver more, faster. The problem is, being good at executing Scrum or Kanban is not the goal. Organizational agility is the goal.

Suppose, for example, you reach a point in your agile implementation where teams are delivering and executing in a much more productive and efficient way. That begs the question, are they delivering the right things? Now that teams can deliver faster with better quality, how does an organization leverage these newly acquired super-skills? 

The answer is clear: the business and product strategies have to change, too. If teams can deliver faster and more iteratively then we need a product or business strategy that can take advantage of these capabilities. It’s not enough to continuously improve how we deliver. It’s not enough to just keep scaling agile to encompass more and more teams. What we must do is improve our ability to figure out what to deliver next. We need to incorporate feedback, learning, experimentation, and rapid delivery into our business and product strategies—without these all we’ve figured out is a faster, better way to deliver the same old results.

What many organizations have discovered in their adoption of agile is that their organizations are rich in policies and controls that were installed to support a process they no longer use. In order to achieve their organizational agility goals, these organizational policies and processes need to be adapted to match the new agile execution, delivery, and strategy models. For example: If existing release management policies require a 3-month conveyor belt to deploy a completed product but the team can deliver completed product monthly (or even weekly), those release management processes and policies must change in order to take advantage of team’s abilities.

To truly pursue organizational agility, we must tackle and transform emerging constraints— things like signoffs, stage gates, metrics, performance plans, risk management, etc. This goes far beyond team-level problems (or even enterprise agile) to the systemic constraints that stand in the way of true agility.

In his 2009 Blog Post (http://bigv.is/xBNZEe) George Schlitz talks about the need to change these rules.  He states:

“Organizations make rules to operate in the presence of limitations…the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations.”

As organizations improve how they operate they must change their organizational policies to deal with new constraints – not treat the existing policies as constraints themselves.

2012 will be the year that organizations start to turn the corner in their agile adoptions. They will recognize that team- or project-level adoption of Scrum, XP, Kanban, Lean (or some combination of agile processes) is only the first step towards achieving organizational goals. They will realize that organizational policies, process, and often, structures, need to change as well. Some will find the challenge too daunting—But those who figure out how to evolve their organizations; those that make it a priority to effect organizational change in order to meet ever-changing markets; and those that realize a sense of urgency and respond to it will find themselves on the path to true organizational agility.

 

Works Cited:

1. Schlitz, George. “Agile Removes Limitations…You Must Now Change The Rules.” Web log post. BigVisible Blog. BigVisible Solutions Inc., 10 Nov. 2009. Web. <http://www.bigvisible.com/2009/11/change-the-rules>.

 

As the interface between Development and Operations, Application Release Management1 handles information that is highly relevant to your Release and Operations teams. Selecting an Application Release Automation solution that provides insight and analytics from both perspectives is thus a key component of an effective DevOps strategy.

Here, we explain how Deployit‘s Infrastructure and new Release Overview features help you achieve this goal.

Continuous Delivery & the Release Perspective

In today’s highly competitive economic environment, the need to bring new features to market quickly, flexibly and reliably is paramount – a goal that is ultimately the aim of the main IT trends Cloud, Agile and DevOps.

Continuous Delivery – extending Continuous Integration to automatically transition applications down the Dev-Test-Acc-Prod delivery pipeline – is a key component of this strategy. In order to be able to effectively implement this, your ARA solution needs to allow your developers – or, in larger organisations, release or DevOps teams, to quickly and efficiently answer questions such as:

• How far is MyApplication down the road to Production?
• When will MyApplication take the next step down the road?
• What do I still need to do before that next step can be taken2?

Ideally, this dashboard would also allow you to plan MyApplication‘s next step and calculate the estimated go-live data, perhaps even based on an analysis of previews versions of MyApplication.

(Virtual) Environment Management & the Operations Perspective

From an Operations point of view, an individual application is only a small part of the picture. Across your Dev-Test-Acc-Prod landscape, you will need to track all applications vying for these environments, to manage potentially conflicting resource requests, plan environment maintenance activities and the like.

Since these environments are often owned and managed by different teams and certainly have varying service levels, you will also want to limit your view to one or a subset of these environments at a time.

Your Operations or DevOps teams need to know:

• Which application versions are currently deployed to my environment(s), or were deployed at a certain point in time?
• Which components do these applications consist of? On which middleware and infrastructure systems are these components deployed?
• What are the current values of any properties or settings for these components? Which environment-specific customizations have been applied?

Cloud and the on-demand environments it enables will eventually replace the rigid Dev-Test-Acc-Prod distinction3. Nevertheless, the ability to present an environment-centric view will still be required, since virtual environments will still be owned by different groups or teams. Indeed, such a perspective will be even more important if you want to effectively combat “virtual sprawl”.

While the coming generations of “true” cloud architectures will hopefully reduce the shared resource conflicts that greatly complicate much of today’s Dev-Test-Acc-Prod management, databases, legacy systems and external payment providers are not likely to disappear anytime soon.

In fact, Facebook, Twitter and other social elements of your future business services may even increase the number of shared resources you need to manage!

Incorporating ARA Data in the Service Delivery Picture

Whilst your ARA solution should be your “go-to” platform for answers about how your applications and environments relate, it is equally important to consider when this data might be more effectively embedded in a broader service delivery picture.

For example, your ARA platform is not a good candidate for providing a release calendar, since it is not aware of much of the information that is relevant in this context, such as CAB4 meeting schedules, business sign-off dates or operational maintenance windows.

It is thus important to ensure that your ARA solution can make its data accessible via APIs such as RSS feeds, iCal calendars and other APIs, to enable effective integrations with the rest of your service delivery tooling.

Conclusion

The right Application Release Automation platform gives your Delivery and Operations teams fast, accurate insight into your application environments and delivery pipeline.

Choosing a solution like Deployit with focused Operations and Delivery overviews as well as open APIs for easy integration into your overall Service Delivery dashboards and reports greatly enhances the accessibility and effectiveness of your application release management.

Footnotes

1. a.k.a. Deployment Automation – choose your favourite
2. For instance, certain blocking release conditions, such as test sign-off, may still need to be met.
3. and have long done so in many forward-looking organisations
4. Change Advisory Board

This post was written by Jonathan Baker-Bates, a UX designer at Hotels.com – @gilgongo 

I’m a designer managing the user experience team here at Hotels.com, where we’re always trying to improve the way we work. It’s a tricky job, because regardless of the organization you’re in, no two UX projects are alike. That’s why the best design teams are the ones that can call upon a wide variety of techniques. A large part of a designer’s skill is knowing which techniques to apply to which projects in order to solve design problems. Designers need the freedom to do this – the freedom to do the right thing.

We define our team’s success in terms of getting ideas to market faster than the competition and executing those ideas better for customers than the competition can. I believe the success of any given method to do this depends mostly, if not entirely, on the environment in which it is practiced. I don’t think it depends on whether you’re PRINCE2 compliant, if you have great documentation, or if your time sheets are up to date – nothing will work if your people are unhappy.

Regardless of the environment, you still must apply a framework that allows the best methods to emerge for your operation. For us, Lean Kanban is that framework, and the best tool to enable it is AgileZen, and here’s why:

First, some background. Hotels.com is a large and very complex e-commerce operation. Well over 200 people work in core operations here in central London, with hundreds of others based around the world. We have 85 web sites in 34 languages, and list more than 145,000 hotels in 19,000 locations. We’re big. We know we don’t deliver the best user experience for booking hotel rooms, but we’re trying to improve that.

My team receives business ideas from the Product Team, and works with them on how to execute those ideas. There are another seven Creative Designers who go on to interpret those executions to suit our brand. My team looks after the customers’ heads, while the Creative Designers look after their hearts.

Over the past four years, we’ve tried various methods of working, including home-brew variations of waterfall and Scrum (you can read about our experience here). Kanban works best for us for two reasons:

1. Enabling us to work on projects in whatever manner we choose. There are no sprints, no estimation, no burn-down charts or time sheets. Stakeholders are welcome to specify deadlines for work but rarely do. Instead, we focus on average cycle times. If an estimate of delivery date is needed, those cycle times can be used to plan accordingly. We have no project managers, because they would have nothing to do.
2. Kanban helps us go faster. The process shows the entire team how much “waste” we generate. Waste takes two forms: time wasted when jobs are blocked or waiting for feedback, and time wasted when jobs are waiting on the board for somebody to commence work. We assume that if it is not waste, it is productive work.

Further, we impose a work-in-progress (WIP) limit guideline. Project team members must not work on more than two jobs at once, thereby keeping the project flow quick and efficient.

Our basic metric is the amount of waste. Compared to hours worked or number of jobs complete, it is clearly actionable information. We reduce waste through experimentation: sitting people closer together, attempts at pair designing, cutting out process stages, etc.

The main focus of attention during our projects’ life cycle is our physical Kanban board. The power behind the board’s throne is AgileZen. When we started with Kanban, we ditched Jira, the tool we had been using until that point. We found most digital tools to be overly cumbersome, time consuming, and an end in themselves. Our team hated Jira because of this. AgileZen became our new solution to make our system work.

AgileZen is a joy to use. We’re designers, so the visual nature of a product counts for a great deal. The API gives us potential for flexibility, and unlike other systems, those parts of it we don’t use stay politely out of our way. Crucially, AgileZen’s project management system makes tracking our work and waste very easy. Every day, we have a team stand-up at which the facilitator simply reads jobs and statuses from the AgileZen screen. We keep the tool in sync with our physical board, which is all about team communication.

Designers are not typically process-oriented people. We want something that fits silently in to the way we want to work. AgileZen does just that and is worthy of its name.

If you have questions about how we’re using AgileZen, it would be great to hear from you in the comments.

After over a dozen years of training and coaching in multiple Agile methods, we've seen how useful it is not to be attached to any one of them. Knowing a variety of methods helps you match the method to the need at hand. It also helps in its implementation. And it gives you the breadth of experience required to keep you from becoming dogmatic. It is easy to forget that just because something...

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

Whenever I use John Deere as an example of a fantastic Agile adoption, I always get looks of surprise. That’s quickly followed by an ‘a-ha’ moment when I share that today’s

From my visit to the test farm in Des Moines - note all of the hardware on top of the tractors

tractors are run by more lines of code than the early space shuttles. Yesterday, ComputerWorld published a great article about John Deere’s Agile adoption, characterized as a ‘big bang’ across their 800-person development organization within a year. It’s definitely worth the 5 minute read.

By 2050, there will be 9 billion people on the Earth.

In 50 years, the world population will require 100% more food. Seventy percent of that food is expected to come from efficiency-improving technology. John Deere considers these their user stories, and they strive to use technology to help solve these global problems. If the ComputerWorld article is worth 5 minutes of your time, then Chad Holdorf’s in-depth talk is worth every bit of 25 minutes to hear John Deere’s bigger vision and how they inspire teams to tackle it at John Deere.

You can work with John Deere too.

I’ve been honored to work with Tony Thelen, director of John Deere’s Intelligent Solutions Group, and Chad Holdorf, their Agile Coach, throughout this transformation. And I share their passion for connecting engineers to solve these potentially disastrous problems. I’d like nothing more than to see some smart folks go to work for John Deere.

With my son in a John Deere plow.

Tractors and Agile? Absolutely. I can’t think of a better example of how software is shaping the world we live in – every single day. Congratulations Tony and Chad and best of luck on your social mission.

Ryan Martens is founder and CTO of Rally Software, a hopeful Citizen Engineer and a recovering Entrepreneur-in-Residence at the Unreasonable Institute. You can follow him on Twitter @RallyOn.

Net als in 2010 heeft Xebia in 2011 het jaarlijks onderzoek naar de de status van Agile in Nederland uitgevoerd. Met ook dit jaar weer opvallende resultaten. Zo zegt bijna 90 procent van de bedrijven die met Agile werken sterk verbeterde resultaten te realiseren bij hun (ICT) projecten. De vraagt die direct bij mij opkomt bij dit soort hoge percentages is waarom niet iedereen met Agile aan de slag gaat.

Daarnaast ervaart 83 procent van de Nederlandse bedrijven die Agile werken hebben geadopteerd, meer werkplezier en 85 procent meer teammotivatie. Dit percentage is aanzienlijk hoger dan vorig jaar, toen gaf driekwart van de respondenten aan meer werkplezier en teammotivatie te ervaren. Dus de mensen die Agile werken varen er wel bij, naar mijn mening een van de belangrijkste redenen voor het succes van Agile. Dit komt ook veelal tot uiting in een lager ziekteverzuim en grotere loyaliteit naar de werkgever toe.

Andere belangrijke effecten zijn een verkorte time-to-market volgens 79 procent van de ondervraagden en toename van de productiviteit (66 procent). Het onderzoek laat ook zien dat kostenverlaging een belangrijker effect van Agile werken is dan vorig jaar (38 procent in 2011 tegen 21 procent in 2010). Niet zo vreemd natuurlijk in deze economisch zware tijden. Maar dit betekent wel dat Agile steeds meer wordt ingezet als onderdeel van een kostenverlagingstraject. Dan is het wel heel belangrijk ervoor te waken, dat met het (meer) sturen op deze doelen de Agile gedachte niet ten onder gaat in de zoektocht naar kostenverlaging. Indien kostenverlaging wordt neergezet als primair doel met Agile als middel, is de kans groot weer te verzanden in ‘ouderwets’ contract en KPI management waarvan we in het verleden nou juist geleerd hebben dat dat niet effectief is.

In de overgang naar het Agile werken is de bedrijfscultuur net als vorig jaar de belangrijkste bottleneck voor veel organisaties (49 procent). En ook dat is geen nieuw inzicht. Maar het is wel iets dat te vaak onderschat wordt, zeker door belangrijke personen die juist onderdeel zijn van die bestaande bedrijfscultuur. De adoptie van Agile vereist veel focus en energie voor langere tijd en de daadwerkelijke borging vindt plaats juist via een inbedding in die bedrijfscultuur.

Door het verbeteren van kennis, kunde en bovenal mindset van Agile zal de uitrol een grotere kans van slagen hebben. De ondervraagde organisaties erkennen dit gegeven zelf overigens ook, want volgens 36 procent is een gebrek aan kennis en kunde de belangrijkste beperkende factor in de (verdere) implementatie en uitrol van Agile. Door juist in deze economisch uitdagende tijden in kennis, kunde en mindset van Agile te investeren zullen organisaties meer rendement kunnen behalen. Het verbeteren van bedrijfsresultaat is nu bijvoorbeeld voor veel financiële instellingen in Nederland een belangrijke reden om Agile te gaan werken: zo kunnen zij namelijk effectief hun te hoge kostenstructuur aanpakken.

Agile belooft dus veel, maar maakt dit ook waar. Zeker gezien de huidige generaties Y en Z die nu opgroeien en de toekomstige werkbevolking van Nederland gaan vormen, is er geen ontkomen meer aan (iets als) Agile. Regelmatig spreek ik diverse (jongere) sollicitanten die Agile, en de manier van werken en omgaan met elkaar die daarbij hoort, heel normaal en gewoon vinden en die gruwelen bij een beschrijving van het traditionele waterval model en bijbehorende werkaanpak. Het aantrekken van jong talent en een werkwijze die niets met Agile of elementen daarvan te maken heeft, staat bijna haaks op elkaar. Blijvende continiuteit en succes op langere termijn voor ieder bedrijf bestaat voor een belangrijk deel uit het aan kunnen blijven trekken en behouden van jong talent. Agile worden of zijn, lijkt hier een belangrijke voorwaarde voor te zijn.

Ik ben benieuwd wanneer u op de succesvolle trein stapt die Agile heet!

The Gist of the Story We believe in Agile software development for teams. From small teams to a 4000 person development group, our clients have enjoyed success with Agile. They have been able to deliver more value to customers at a more sustainable pace and with greater employee satisfaction than ever they were before. That is what keeps us going. We believe in Agile in all its flavors:...

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

How do you change the way you live or work? Many people, and companies, seem to think it’s enough to adopt just one or two practices. While they continue their old habits, too. Will this lead you to your desired outcome? Or will you just get frustrated? 

The desire to change

Suppose one day, after a particularly bad hangover, you decide to change your life.  You long for a trim body, a balanced spirit, lots of energy and no more headaches. In short, a happy mind in a healthy, good looking body. But how do you get there?

Well, we all know that there are many practices that will help you achieve those goals.  Exercise three times a week, stop smoking, reduce your alcohol intake, and change your eating patterns. Oh, also, get more sleep, less stress, no more pills, and drink herbal tea instead of espressos.

But you hate sports, you love chocolate and smoking is your way to reduce your stress.  So what do you do?

The daily fruit practice

In order to get healthy, you decide that from now on, every day, you will eat a piece of fruit at lunch.   It’s pretty easy to do, even though you don’t like fruit very much.  So now you are satisfied, you do a healthy thing every day, and you expect to reach your goals (more energy! greater happiness! better looks!) anytime soon.

Will you? Of course not! While the daily piece of fruit is a step in the right direction, you will never fully get the benefits you are seeking if you keep up your old habits of smoking, drinking and eating greasy food,. And after a while you might even get disappointed and frustrated, and you will decide to stop eating fruit, claiming that “a healthy lifestyle simply doesn’t work for you”.

Doing just one healthy practice, or even a couple of them, isn’t enough. What you really need is to change your mindset. You want to be a healthy person, not do some healthy stuff. Once the healthy mindset becomes your way of life, the practices will simply be the natural way to go. And they will be a lot easier to start with and maintain for a long time.

The daily Agile practice

The same applies to Agile. We see many companies and teams that ‘ do‘ Agile. They take a couple of practices from an Agile framework such as Scrum, and they figure that that will be enough to give them all the Agile benefits. Some teams even think that if they just do a daily stand-up, they do ‘ Agile’.  While daily stand-ups, just like that daily piece of fruit, are definitely a good practice, your are still far removed from true agility if the rest of your behaviour consists of old, non-Agile practices.

A company or team only gets the most out of being Agile, when its mindset is based on the Agile principles stated in the Agile manifesto, such as continuous learning at all levels in the organization, business and IT working closely together, delivering the highest business value first, welcoming change, and creating an environment where motivated individuals can be creative and self-directing.

So if you are doing ‘some’ Agile, expand your practices. But more importantly, change your mindset. Don’t do Agile, be Agile. And remember:

One practice a day does not keep the old habits away…

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.
Manage Both the Big Vision and the Small Batches

Keeping a balance between the development of product qualities that will fulfill the business case and the tactical execution of low-level features is perhaps the most important skill possessed by a Product Owner. The difficulty in simultaneously doing both of these things well often leads to an actual split in the role, where a “Strategic” or “Chief” Product Owner focuses on the big picture, and the “Tactical” or “Proxy” Product Owner works with individual teams attending to the details of execution. Tools like story mapping, product trees and personas are commonly applied at the big picture level by Strategic POs, while sketches, wireframes, process flows and various collaborative modeling techniques are generally employed by Tactical POs to help teams better understand and execute the details.
Strategic product ownership is focused on garnering feedback and testing the project's assumptions at the vision and business case level, while tactical product ownership should align the whole team against small batches of work within sprints to ensure the best execution possible at the detailed level.
Test the Project’s Assumptions
Business cases are often presented as foregone conclusions: Build the features, and they will come. However, there is no shortage of failed and unloved products to prove that this is nonsense. Projects are built upon more or less educated guesses of what the market and stakeholders need and desire, and it is the Product Owner’s job to test and refine these assumptions, thereby guiding change through objective data.
Techniques such as customer development in the "Lean Startup" approach focus on stating your assumptions in such a way that they can be tested, and then using feedback from these tests to adjust the project’s focus. The simple process of coming up with metrics that represent the product’s desired qualities and impact areas also can be of tremendous help when attempting to balance diverse needs across disharmonious stakeholders, as it forces a focus on overall project needs rather than individual features. In essence, the why must precede the how.
Use the Whole Team
When Scrum was first formulated, a joke cast the “team” as committed “pigs” while the Product Owner (along with general stakeholders) was dubbed a merely involved “chicken.” This is an unfortunate place to draw the line, because these two roles work best as a tight-knit partnership. Scrum teams already play an active role in design and feature elaboration, and the best products come from fully engaged teams, not ones that simply wait for their orders or ones design in a vacuum.
Collaborative modeling techniques, where designs are created and refined by small groups rather than individuals, are common in such environments. Finding the right balance between giving the team a “final, approved” design to develop vs. involving them deeply in the design process itself isn’t automatic or consistent across teams, but it is the only way to maximize both the efficiencies so often touted in Agile methods with product innovation, effectiveness and quality.
I hope you've found this post useful. If you have any other questions about how to be an effective Scrum Product Owner, share them in the comments and I'll do my best to answer all of them in future posts.
Subscribe to RSS Feed

TestLodge recently announced their latest feature that allows Assembla users to link their accounts to TestLodge's test case management tools. This integration makes many essential software testing features available to Assembla users without having to manually enter data for their tests and bug tickets multiple times. TestLodge created this custom integration using Assembla's REST API.

This first iteration from TestLodge offers the following features:
 

• Automatically create tickets in Assembla in the background when a test fails. Each ticket includes a description and steps to replicate, along with the expected result and actual result.
• Optionally, choose who the Assembla ticket should be assigned to, and set the priority.
• Associate an Assembla project workspace with a TestLodge project.
• View a test report that provides links to all created tickets.

About TestLodge TestLodge is a relatively new hosted tool that is designed to be a lot simpler than the traditional test management software by providing only the essentials to get the job done well. The system focuses on helping you create your test plans, input your requirements, create and manage your test suites & cases, and allow you to easily perform multiple test runs & generate reports.
Special offer As an introductory offer, TestLodge is offering a 20% discount for a limited time to anyone who makes use of the new Assembla integration. Simply sign up for your TestLodge account, then email TestLodge about the discount within a week of signing up.

After releasing our GitHub integration last week and seeing all the positive feedback, we figured Bitbucket should be the next up, another application for source code hosting. This integration works in pretty much the same way as the GitHub integration, so teams that use both Bitbucket and AgileZen can now associate their commit messages with story cards! Please review the Bitbucket article in our knowledge base for detailed instructions on how to get set up with this integration. Once you’re up and running, you can comment in your messages with the AgileZen story card number and have the commit message appear under the changeset list on the story card.

We hope you’ll check it out!

While we were building a little server to enable auditlogging on our hadoop cluster (more on that in a future blogpost) we needed a way to distribute our application.
This blog is about the packaging of this application. The application is build with nodejs and packaging and dependency management is mostly done with npm (the node package manager).

Of course installing this application in the production environment should have been as easy as the setup on our own laptop’s right? Wrong! On our laptops it was a easy git clone followed by a npm install and voila we have a running application. So how hard could it be to do this on a server at the client. Let me tell you….

This server is not connected to the internet, so the git clone wouldn’t work in the first place. Not really a problem because it’s a small app and we could just make a tarball and ship it to the server.
Next thing was all our dependencies. We used a few modules which were mentioned as dependencies in our package.json file so npm with the install command would do it’s magic.

The npm install magic consists, among other things, of getting the modules from the npm registry and that fails if you’re not connected to the internet. Searching for a way to do this differently I figured out that npm had a cache directory and thought I could get the stuff from there. This might have worked, but with that solution I would miss the dependencies where these modules depended on. And it would be a messy kind of script that I needed to make.

Browsing the internet didn’t provide me with the right answer but it led me on the path to the npm pack function. This is used to pack your module together with all dependencies. The only thing you need to configure it correctly, is a separate array containing the dependencies to bundle with your app.

So far so good, so I went on and added a bundleDependencies section in my package.json and ran npm pack.
The result was a nice .tgz file containing all the files needed for the application together with all the modules it depended on. At least the main modules it depended on. My fellow programmers in crime from which I got these modules hadn’t bothered to add this extra section, so npm had no notice of the modules they depended on.

This was easy to solve. Just add a correct section of bundleDependencies to all package.json files.
Sounded like a boring task to do this manually and because I love my programming job, I decided to write a program for it.

My obvious choice of programming languages was: awk, grep and sed. Why? Because I can.
Without further ado, here it is:

    awk '/dependencies/,/]|}/' $file |
    grep -o '\".*\".*:' |
    sed 's/^.*{//g' |
    sed 's/\"dependencies.*\://g' |
    grep -v -e '^$' |
    uniq |
    sed 's/\"[ ^I]\:/\",/g' |
    sed 's/\"\:/\",/g' |
    sed '$ s/,/ ]/' |
    sed '1 s/\"/\"bundleDependencies\" \: [ \"/' |
    sed 's/\"/\\"/g' |
    tr -d '\n'

What it does, you ask?
I'll explain line by line:

line1: get the dependencies part (an array or json object) from the file (the package.json file)
ex: "dependencies" : { "express": "0.2.2", "findit" : "0.0.1" }

line2: get only the stuff from that object between the double quotes before the colon (removing the version number part of the dependency)
ex: "express":
"findit":

line3: remove anything preceding the {
line4: remove the original dependencies text
line5: remove any empty lines
line6: remove duplicates

line7 and line8: replace the ": by ", so we can create an array from it
ex: "express",
"findit",

line9: replace the last , by an ] to close the array
ex: "express",
"findit"]

line10: replace the first " by "bundleDependencies" : [ "
ex: "bundleDependencies" : [ "express",
"findit"]

line11: precede all quotes by a backslash so it can be safely used in the sed command to add it to the file

line12: remove all newlines
ex: "bundleDependencies" : [ "express", "findit"]

This is added to the package.json file we are currently processing and if we have finished doing this for all package.json files we can use npm pack to create our tarball.
Works pretty well I might say. But I'm the first to admit this isn't the most readable program ever written.

Of course when building a node application you might have node around to help you do this so I also created a javascript version to do this:

var fs=require('fs')
var findit=require('findit')

findit.find('.', function(name) {
  if (endsWith(name,'package.json')) {
    handleFile(name)
  }
}).on('end', bundleApp)

function handleFile(file) {
  var data = fs.readFile(file, function(err, data) {
    if (err) {
      console.log('Not processesed '+file+' bo the following error: '+err)
    } else {
      var arr = []
      var packageFile = JSON.parse(data)
      if (packageFile.bundleDependencies) {
        console.log('Bundledeps already present. Skipping')
      } else {
        for (var d in packageFile.dependencies) {
          arr.push(d+"")
        }
        if (arr.length > 0) {
          packageFile['bundleDependencies'] = arr
          fs.writeFile(file, JSON.stringify(packageFile, null, 4))
        }
      }
    }
  })
}

function bundleApp() {
  console.log('Finished. preparing package.json files for packaging. Now run npm pack to create the fullblown tarball')
  //exercise left for the reader to require('npm') and run the pack command
}

function endsWith(str, suffix) {
  return str.indexOf(suffix, str.length - suffix.length) !== -1;
}

Hope somebody can benefit from this in the future.

We love supporting the open source community, so we decided to integrate with the Project Hosting on Google Code, a free collaborative development environment for open source projects. Our integration with Google Project Hosting allows you to associate commits in your Google Project with story cards in AgileZen. This lets your team stay up to date on the latest development work and view a history of commits for each story. If you’d like more information on how to set this up, please check out our knowledge base article.

If you’re actively working on an open source project and want to use AgileZen to manage your work, we have a free account with one project and unlimited collaborators specifically for open source! Please contact us at giving@agilezen.com with information about your project and a link to your repository, so we can get you set up.

Guest post: Patty Beidleman, Elementary Educator Many of you may know our next guest blogger, Patty Beidleman, from Twitter where she she’s well known in Lean / Kanban community as @topsurf. She’s been a friend and inspiration for us at LeanKit since the early, early days of the company. We’ve been impressed by her passion [...]

Firstly, I'd like to say thanks to everyone for the wonderful comments received in regards my writing. Frankly, I am flattered. I'd also like to apologize again for not writing more regularly. It seems like I just never get the time these days with my busy life. The scenario I want to specifically talk about today is as follows: You plan a Story into a sprint, let’s say an 8 point Story, but the team doesn’t get to finish the Story. How should you account for the Story Points in the current and subsequent Sprints? Let’s just say for explanation's... Jack Milunsky

As of 6:10 PM US Central Standard Time (GMT -6) LeanKit has completed our migration of the Kanban system to our new hosting environment in Reston, VA. All manual and automated testing and monitoring indicate that full service has been restored. We already see normal usage by a number of business and personal kanban customers. [...]