Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...A History of Kanban for Creative Knowledge Work October 2004
Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.
Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month.
One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates. So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers. A classic game (Innovation Game) to expose these impediments is Speed Boat.
I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game. See the article by Alan Dayley Velocity is Like a Helium Balloon to get a hi-res poster.
WARNING: Shameless plug for my session at Agile2014 ahead.
I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.
In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.
Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.
Here are some factors that I think go into figuring this out:
- Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
- Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
- Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
- Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
- Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.
How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.
So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:
Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)
And here’s the formula in action:
Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.
Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.
Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.
In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.
I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.
But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”
I am probably crazy-optimistic. But that hasn’t stopped me before.
I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.
Thank you very much.
Forgive me for bringing up show tunes. I love the old musicals. One of the true classics of American theater is the show Oklahoma. I got to thinking about this in a very roundabout way the other day. The song, called “With Me It’s All or Nothing” got stuck in my head. Let me tell you why…
If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?” These questions are fun to argue about. They are mental candy. But the bottom line is, just like candy, they can also be bad for you. If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development? Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts? I don’t think it does.
The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief that we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work. If you have an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”. I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.
I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal. The real power of Agile software development is not the fact that you do things in smaller increments, or that you write your code test first, but in the supporting power of each of these elements. The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing. Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms. If you didn’t want mushrooms, why did you order the pepperoni and mushroom?
This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development. The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required. After a while I couldn’t help but ask “why are we arguing about this?” The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming. You see, with me it really is All or Nothing.
I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”
When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.
I bet you’ll enjoy it!
In my role as technical editor for agileconnection.com, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.
One such comment is what do teams do? Do they “gel” or do they “jell”?
Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.
Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.
You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.
So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.
If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.
XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.
To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.
Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.
As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is more than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scatches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.
As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).
We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.
There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resiliant to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!
Axosoft is all about being healthy, from our tower gardens in the kitchen, to our daily workout classes in our office gym. But last month we took it to a whole new level…
THE 28 DAY CHALLENGE
Confused? You should be, I haven’t explained what it is yet.
The 28 Day Challenge is a healthy eating initiative that we decided to put into effect at Axosoft. We thought it would be a great way for everyone to start eating right and getting healthy in a supportive team environment.
The challenge involved 3 different steps:
1. For 28 day we would give up one, or all, of the TEN DON’Ts:
1. No wheat
2. No corn
3. No dairy
4. No soy
5. No refined sugar
6. No caffeine
7. No alcohol
8. No dried fruit or fruit juices
9. No artificial sweeteners
10. No fat-free “diet foods”
2. We would eat only the foods from 3 phases, spaced throughout the week:
Phase 1: Eat only Fruit, Veggie, Protein, and Grain
Phase 2: Eat only Veggie and Protein
Phase 3: Eat only Protein, Fruit,Veggie, Grain, and Healthy Fat
3. While eating the foods in these phases, we follow the TEN DOs:
1. You must eat five times a day. That’s three meals and two snacks per day.
2. You must eat every three to four hours, except when you’re sleeping.
3. You must eat within 30 minutes of waking. Every day.
4. You must stay on the plan for the full 28 days.
5. You must stick to the foods allowed on your phase. Religiously.
6. You must follow the phases in order.
7. You must drink half your body weight in fluid ounces of water every day.
8. Eat organic whenever possible.
9. Meat choices must be nitrate-free.
10. You must exercise three times per week.
I’m not gonna lie, it was tough, really tough. There was a lot of good stuff we were giving up and a lot of rules we had to follow. Many of those DON’T items were in our stocked kitchen and had to be removed… that almost caused a riot. The items were replaced with healthier and phase approved snacks, but they did not have the same sugary, salty goodness we all liked.
The fact that there wasn’t a caffeine deprived murder in the first week, is amazing. Also you have no idea how hard it is to eat every 3 hours while drinking half your body weight in fluids, the combo caused some impressive lines at the restrooms.
But we stuck with it, and at the end of the 28 days there were some awesome results.
- Mike lost 13 pounds.
- Mona lost 12 pounds.
- Allen lost 15 pounds and his wife, who decided to do the challenge with him, lost 13 pounds.
- Gus started losing so much weight that he had to drop out of the challenge or his wife threatened to divorce him.
- Lawdan began sleeping better and no longer needed her allergy medicine.
- James liked having the healthier snack options in the kitchen.
- Jonathan lost 10 pounds and admitted feeling a little sexier towards the end of those 28 days.
- Hamid was surprised at how easy giving up coffee was.
- Sara liked how the plan helped her figure out healthier snacks and meals.
Everyone agreed that having the team environment made the challenge much easier. And probably the best result of all is several people have kept following the healthy eating initiative, even after the 28th day!
GO TEAM AXOHEALTH!!!
I’m subscribed to a newsletter from Buffer, a startup softdev company that develops an app to manage multiple social accounts. It’s quite an unusual thing for a social media-related company to share sensible advice in their newsletter, and that’s the reason I wanted to learn more about that company. So, I googled all things Buffer. The more I researched, the more I admired them. They are a startup, and they do well, generating over $3 mln in annual revenue, with only 23 people. What is the reason for such an amazing performance? How have they been able to grow from zero to a revenue-generating company, in 3 years, with a lean squad of people, and still bootstrapped? How do they keep up their productivity?
The answer came with a little bit more of research. Buffer don’t wrap their rules of operation in the toga of productivity, or agile, or development process lingo, which is very unusual, and which might explain why this company performs way better compared to the others that do. What’s more, Buffer keeps their people happy and emotionally fulfilled. They don’t think of their company as a racing car that has to be ramped up on speed. They, actually, are not concerned with productivity, or speed, for that matter, at all. The point is: Buffer spotted this one bottomline thing that powers productivity. They refer to their rules of operation not as to policy, but as to culture. And, the way I see it, the ultimate key to their performance is one simple thing called clarity. Check this snip from Buffer’s culture statement.
It might be hard to believe at first, but with a little bit of thinking, we will see that clarity is the key to productivity for any team’s work. Thinking logically, a team’s performance is a sum of smooth individual flows and actions. Developers write code, QA engineers do testing, someone is in charge of automated tests, designers do all things UX. Now, when productivity suffers? As with cars and highways, stops occur when there’s a roadblock or a speed bump of something not being clear. What happens if bumps accumulate for weeks, even years? Production team lose track of priorities and incentives, if a day’s work is filled with un-clarity every step along the way. What should I do in this case? Who do I contact? Who has a clue to this problem that I have? If people in the team fill most of their days with these questions, it’s time to put up a huge red flag and “beware bumps” sign. In this sad case, the team is deprived of the very chance to perform, even if they want, because, individually, they lack clarity. They need to have a clear knowing of those “who, what, why, when, how”-s related to their work, or, at least, they need a fast and smooth way to get the answers. If finding an answer for a repeated daily task becomes an ad hoc improvised quest, R.I.P. productivity. The things covered under the umbrella term of “efficient development process”, are rooted in crystal clarity.
Clarity is also crucial when it goes about motives for the actions of others. Second guessing, or a misunderstanding about someone doing things the way they do them, is another severe case of un-clarity. Generally, we are supposed to assume that everyone is doing their job as best as they can, but, with lack of clarity, the thing that I call “assuming dumbness” rears its ugly head. When it happens, instead of having it clear why someone in a team has done a code, or a test, or a copy, or a design in exactly that way, others make a default assumption that this person is “dumb”, not competent and not knowledgeable. This isn’t a productivity killer, per se, but it is a dangerous team spirit killer, and I hope you haven’t spotted this in your team.
As we can see, there’s no need to go any further and re-invent the wheel. If you’re concerned about bad productivity, or if you see that people look exhausted, unhappy or loose, seemingly giving up on their work, they crave for someone to champion clarity. That’s what Buffer calls “Default to transparency“, which is a sibling of clarity.
So, ask yourself, do you always have this clarity? In your team? Is your day made up of roadblocks, or is it filled with gratifying work which goes in a seamless flow? If no, take action. Go for clarity. Demand it from your managers. Clarity is this so much wanted silver bullet for productivity in a software development team. If you find ways to instill the culture of clarity in your team, every step along the way, the Holy Grail is yours.
Do you have a set of budgeting, funding, and approval processes so complex that nobody knows how they all work? Is the easiest way to get something done at your company to escalate to a senior executive, or go straight to a developer?
The other day, I was helping a customer untangle their approval/funding/budgeting processes. Now, this may not sound like the most delightful afternoon, but it was hot outside, and we were all ready to do it.
The company already has adopted some parts of SAFe -- they’re doing mid-range planning once per quarter in a big meeting, and getting better and better at delivering on those plans. But invariably, a half-dozen program managers and stakeholders would appear at those meetings wondering why their budget-approved projects weren’t in the backlog.
As it turned out, the budgeting and approval process was pretty Lean already -- but it was completely disconnected from PSI planning.
A small group of people was great at validating new business opportunities, rapidly exploring them, and deciding whether to fund them, all in a matter of hours or days. Once a project got approved, the project manager was then free to go off and try to get resources allocated -- either hiring people, or getting them reassigned, or just peeling off 20% of their time.
This approach was a relic from the old waterfall ways of working. We’ve all seen these resource battles, and I realized on that hot afternoon that this wasn’t just a benign approval process.Beware the Resource-management Jungle
This process was granting hunting licenses.
That is, project and program managers were heading out to hunt for people to enlist on their projects.
Are you doing this? Are you doing a careful job of approving work, only to send people off into a resource-management jungle armed with nothing but a budget, a business case, and a set of relationships?
If so, you might find that there’s a lot of wacky resource contention going on. You might even find people caught in the crossfire as project managers compete to capture their resources. (Is that the elusive senior engineer? Trap him in your team room! Promise him free lunches if he stays!)Prioritize Your Backlog
So, what’s the alternative? It’s actually quite simple. The approval process has to feed into a backlog of initiatives. You’ve got to get your senior leaders to prioritize these initiatives based on your planned spend in different investment themes. This prioritization then feeds the backlog of work that goes into your mid-range planning meeting.
Then, when your teams actually plan out the work, you can see whether they’re actually working on your top priorities and adjust accordingly.
When you start your project depends on its priority, but it also depends on the number of initiatives you’re already working on (your WiP, or Work in Progress). Just because your initiative is approved doesn’t mean it should start right now.
If the wait to start a new project is too long, that’s just a clear sign that you’re already working on too many things at once.
So your approval process shouldn’t grant a license to hunt resources. Project approval doesn’t mean you’re authorized starting the work immediately. It just means, “This thing seems like a good enough idea that we should prioritize it against all of our other opportunities.”
Modern Agile portfolio management suggests using the team as the resource unit. Read more about it here.Alex Pukinskis
Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.
If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.
I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:
- Keep the team working together closely and will result in less context switching
- Keep the intensity level high on getting impediments resolved ASAP
- Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
- Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day
The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.
If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.To get started, click on the desired integration below:
Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.
Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple
I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.
Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:
- Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
- We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
Tags have always been an important tool in Sprint.ly. Tagging items allows for targeted filtering and is a central feature for organizing and prioritizing sprints and iterations. Today, tags get even a bigger spotlight.
Our team is excited to announce the beta release of a major new Sprint.ly feature: Progress. We designed this report to show burn down and measurable progress over time for each tag in your product.
- “Give me a progress report.”
- “When will we be done?”
- “How much work have we finished so far?”
- “Who do we have working on this?”
- “What tickets are we working on?”
Progress answers these are the critical project needs and questions.
Progress has been released in beta to a handful of our customers and we will be spending the next few weeks gathering feedback. We’ll incorporate the feedback and release it to the rest of our customers on select plans within a few weeks.
I’m thrilled to share this new feature and as always, I had a great time working with our Sprint.ly design and development team on it. In the words of our founder Joe Stump “Wow. I am excite.”
P.S. Progress told us when we would be done with this feature and yes, it was right!