Getting your data in and out of an web based system is really important. It’s great to be in “the cloud” but you should not sacrifice control and ownership of your information. That’s why Agile Bench has both importing and exporting capabilities.
Import and Export actions
Import
If you are moving from another system, or just wanted to give Agile Bench a try with your real data, then why retype everything? You shouldn’t! We’ve built a way for you to import your stories right into Agile Bench.
Fields that can be imported (Click for larger view)
If your data is in another online system you should be able to export it into a CSV file (and if you can’t, that should worry you) and then upload. We know a lot of people use Excel as their project management tool which also allows you to export your data as a CSV.
Now you are up and running with a minimum of fuss.
Export
Exporting your data is even more straight forward than importing your data. You’ll get the following fields: ID, Title, Story Type, Estimate, Current State, Deadline, Created At, Details, Iteration Name, Iteration Position.
Export your project for use in Excel (Click for larger view)
Going forward – the API
We want to make it easier for you and your company to manage their data. We are really excited to have an API in beta mode. If you’d like access please drop us a line.
Tags:csv·data·excel·export·import·openoffice
Agile should be the product managers friend, but at times it can feel like you’ve lost all control especially when you can’t work on product development 100% of the time because of all the other things you have to get done.
So what should you do, do you hand off your other responsibilities to the marketing team or do you bring in someone to work full time on product development. From our point of view it depends on where you are in the product lifecycle, how your organisation is set up and what your strategic priorities are.
The folks over at Pragmatic Marketing talk about 2 different types of roles. A product owner (a scrum term) who sits within the agile development team and defines requirements, removes roadblocks and researches new functions and a product manager who sits outside of the development team but who has ultimate responsibility for the product being brought into the market place. In some cases they feel the 2 roles can be covered by an experienced agile product manager and in other cases they are split.
If you do take on the role, agile product management is not for the faint hearted. You may not be used to being so close to the development team, delivering your product in an iterative manner or not fully knowing what will be delivered until it is, but don’t worry you’ll get there in the end and it always helps to have some one around who’s been through it before. Some of the pitfalls to avoid include being tempted to change requirements or drop in new features during an iteration, spending too long documenting features or not planning what you want to deliver a couple of iterations ahead remember of course your plan may change.
In the end, agile won’t solve all of your problems. You still need to get out there, talk to your customers and shape the information you gather into something that your team can deliver. What it should do though is bring you closer to your product sooner than you would have normally been, which hopefully means you don’t get that confused feeling at the end of a project where you wonder why on earth the team built what they did.
Here are few articles, presentations and books we have come across that should help you out:
Tags:Agile·PM·ProductManagement
After using Agile bench as much as we have, you soon realize that it’s a bit of a chore having to navigate to the edit story screen to update story details, so following our standard rule of thumb of if it makes our lives easy it will make your lives easy to, we have implemented in lined editing. Just click on the story from the iteration management page and you can update the story title, assigned developers or delivery estimate.
To go to the full story edit page, just click on the arrow head to the left of the story ID.
Tags:
We find this is one of the most common questions asked within the companies we have worked and with the people in our teams.
The typical view of agile is that its all about hacking the code, no documentation and developers going off and doing their own thing, whereas with UX and User Centred Design (UCD) in particular the view is that it all takes too long, the design has to be perfect, we have to check with all of these users and we could have built and launched it by now…
The key issue seems to be how do you fit some of the fundamental UX methods into the small iterations that Agile develop teams work. A lot of teams run parallel design and build iterations, so that the design team has the time to create concepts and test them before handing them over to be built. This approach works but doesn’t really fit in with the agile principles of a team working together on discreet pieces of functionality within the same iteration
Another way to bring the teams together is to extend the scope of iteration 0 by not only looking at planning but also defining a high level information architecture, because changing this halfway through a project is very painful. We are not talking about Big Design Up Front (BDUF) but just enough so that you can understand how the product fits together.
In the end we think it comes down to the people more than the process, if the team wants to make it work they will find a way, just as the Agile Manifesto says it should.
We don’t think we have the perfect answer and there are lots of resources out on the web on this subject, below is a list of links to other articles, presentations and blog posts that we’ve read along the way.
Tags:Agile·UCD·UX
Agile is a term many people have heard of but perhaps don’t fully know what it means. Agile refers to a group of software development methodologies and techniques based around iterative development where requirements and solutions evolve over time through collaboration of cross-functional teams.
The key premise behind the agile movement was that traditional software development approaches (typically termed waterfall approaches) took too long to deliver working software and typically solved the problem identified at the start of a project which was often not the same problem that needed resolving by the time the software was finally delivered.
Agile aimed to deliver software quickly through close collaboration, iterative development, continuous testing and frequent deployment. This meant the “business” could get its hands on working software much sooner, which reduced confusion around what was actually being delivered. The agile banner covers a number of methodologies, these include Scrum, XP, Crystal, DSDM, Evo and others.
All of these methodologies encompass similar principles and are based around the 4 key pillars of the agile manifesto namely:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Here at Agile bench we love agile because of it’s pragmatic approach to building software. It’s about business benefit, building for the now with an eye on the future, focusing on how our software can make a difference to the bottom line and collaborating with out colleagues instead of creating barriers between departments. It’s about the business benefit we deliver not the job titles we are given.
Here are some links to further reading about agile development:
Here are some books you may want to read to get started on your agile journey:
Tags:
Having used personas a long time ago at the BBC we are now using them again to define and validate features for Agile bench. I’m keen to make sure they are as real a possible and a friend pointed me a post by David Travis on Creating personas your design team will believe in, a definite worthwhile read.
Tags:
Before Shot
The first release of Agile Bench was built over the last 9 months (yes that’s a lot of weekends and nights). We wanted to get a product into production as quickly as possible so we created an Information Architecture (IA) based around our domain model and then released this version to a group of close friends. Once we were in alpha, we started to use Agile Bench to manage our own project which was a real eye opener, it didn’t take long before we discovered some key issues that needed to be resolved, part if this was own to the IA, primary activities were elongated due to navigational and flow issues.
To take Agile Bench to the next level ready for a full release we decided to use a persona based approached to rework the IA.
We defined 3 key personas, a delivery manager, a developer (to cover tech, UX and testing) and a product manager. Firstly we gave the personas some background including previous experience, focus and responsibilities. Then we identified the tasks that each persona would undertake and prioritized them based on how important we thought they were to project success.
After Shot
Once we had identified the key activities we reworked the IA to make those activities as straight forward as possible putting the right information in an easy to understand structure.
As you can see from the before and after screen shots, the IA of the site changed quite dramatically.
The persona based approach worked really well and we plan to continue using these key personas to design and deliver future requirements.
Tags:
Agile 2009 is huge. There are 1350 people with 23 streams of talks across 2 buildings, which is pretty crazy. It is impossible to get across the entire line-up of talks so you have to be selective. Thankfully the sessions are divided by experience, persona and some more general groupings.
The persona divisions are pretty interesting. There are the traditional agile personas such as software developers (experience and new to agile), testers and business analysts. These sessions are focused on making you better at your skill-set within an agile environment. The agile community, and more generally, people new to agile, focus a lot on becoming more proficient in their current domain. There are great resources on pair programming, refactoring, test-driven design, mocking and stubbing and basic project management around and have been for a while.
Software development is a microcosm of product development and to build great products you need (gasp) more than just software developers, testers and analysts. The UX, product management and leadership (as opposed to management) communities are starting to be represented more equitably, which is a good thing for the Agile community. When these communities collaborate together we build better products which is something we all value.
With the establishment of the “PMI Agile Community of Practice” http://ow.ly/llUl project managers are moving closer to the agile community that will be good for both communities.
But there are a few major personas missing. On the delivery side, what happened to the system and database administrators? On the organizational side where are the accountants?
The fact that the Agile community is becoming more inclusive of other disciplines is great. But has it gone far enough?
What do you think?
Tags:agile2009
The first release of Agile Bench was designed around the issues that have affected our own agile projects. We’re now thinking about what should come next and we wanted to understand what other agile teams think makes the difference between good and bad projects, success and failure.
To help us with this, we’ve created a small survey, it should only take a bout 5 minutes to fill out and we will be publishing the results on our blog around the middle of September. It would be great if you could take the time to fill it out - Agile Practices Survey.
Thanks in advance from the Agile Bench team.
(PS if anyone is thinking about doing a survey for their own project then I can’t recommend WufOO more highly, this app is really easy to use and gives you a lot of control over look and feel.)
Tags:
We’ve been involved with software development since the mid 90s, initially using waterfall type methods and then with agile approaches such as Scrum, XP and DSDM. What we realised was there wasn’t a standout tool that could help us run our projects. We wanted to create a tool that supports the key activities that make the difference between a project being a success and a failure.
Agile Bench helps you plan and track your project, it improves project communications and ensures that everybody on your team knows what’s going on.
We’ve started this blog to keep in touch with you, to let you know about the new features we plan on building and to get you feedback on what we’ve built so far. We also hope to give you our thoughts on agile development practices, what has worked for us in the past, where we’ve had problems and what other agilists are talking about and doing.
So, thanks for checking us and Agile Bench out. Hopefully we’ve grabbed your interest so why not ty us out, Agile Bench.
Tags:
