Drupal 8: an agile proposal

Drupal 7 is out. Even before the release, the community already started thinking what should happen for Drupal 8, we're just too excited to keep on working! Keeping track of which bugs, tasks and feature requests should be developed is gathered from a lot of sources and eventually - not always - created as an issue in the Drupal Core issue queue. Looking at the size of that queue, we already have a lot of work, most of which are tasks/bugs/follow ups which didn't make into Drupal 7.

New features will obviously come up: proposals and discussions are found on blogs, groups.d.o and Community initiatives. Brainstorm sessions happen at Drupalcons, IRC, local gatherings of Drupal enthousiasts or even surveys. Tracking all this activity and the current work is really hard, probably nearly impossible for every single person on this planet. Also, issues marked as critical give a false sense to me sometimes since the spectrum of things to fix is simply to wide and not focused on making sure a single piece of code is 100% A-OK. You can bookmark several URL's which lists issues based on tags (performance, theme, favorite-of-dries ..), components (node module, etc), priorities (major, critical) and so on. Simply too much to handle for one person.

What's next ?

The biggest personal issue I have, is that I'm not certain by any means what will be in the next release. As an example, take a look at the feature list for Fedora Core 15. It gives me a clear overview what I can expect the next time I'll be updating my development machine(s). I'm able to read a full description, track changes and see the progress of every single feature. That's nice and comforting for me. I would really like to see such an overview for Drupal core too. It would allow me to choose in which areas I want to be involved in and I can rely others to work on area's I'm less familiar with. A nice list like this would finally bring an end to the phrase "when it's ready" on the question when a new Drupal core sees the light.

So what if we started developing Drupal 8 in an agile way, using Scrum or - our favorite at work nowadays - Kanban ? The latter allows us to bend the rules much more in a way that it would fit our situation, in our case, a gigantic community spread all over the world. What do we need and how could we possibly achieve this so we can throw out another kick ass release ?

Roles

In an agile process, several roles are defined each having their responsibilities. Most are known, but we'll define them for our excercise.

  1. Product owner: In some way, everybody owns the product as we all have our ideas. But Dries, at the very end, decides which new features need to be in the next major release and what's left out.
  2. Project managers: Together with Dries, the core committers who test the stories, make sure sprints are delivered on time, discuss and resolve problems towards developers, consulting both the latter as the PO.
  3. Scrum master(s): This is the hardest task. They are responsible to solve problems on the story level, report to PM and PO, guide developers and testers, solve interrelational problems. Experienced people who know how Drupal Core works already, not necessarily on on every level, should be appointed for this role.
  4. Developers: the community. And boy, are we lucky, we have a gigantic pool of resources. But this does not only include hard core coders. People who like design, user experience, information architecture etc. must be involved at all times too. We've seen a lot of good input from a lot of those types, but we need more, a lot more!
  5. Testers: We have a great test bot. But it can't beat every day point and clicking by the average user who will use the product on a daily basis. However, it's ridiculously easy to come up with use cases nobody has never thought of during the process, the clue will be to filter out the critical ones. 

Release planning

Before we all start coding on new things, let's try and find out what the product owner wants to see in the next release. Obviously the PO will have some wishes and as identified above, we already have a big backlog, but priorities are not always clear. In this planning, this should be made clear what is really necessary to be picked up first. Because, the sooner this is done, the better we can focus on the nice to haves. A closing deadline always brings bad advice!

Planning this meeting is not going to be easy for the scrum master. A workable solution is an IRC session on a time it fits for the biggest amount of people, and still, even then some will not get up at night to participate. This can be tackled that already a number of spoke persons stand up voluntarily so they can express the wishes and conceirns from the community. Important is that there can't be a big discussion on technical level, there's just need to be an agreement on a fairly abstract level. Stories are written with a rough estimation, tasks can be assigned, but this not necessary during this meeting. 

Backlog filling

Sprint planning

This meeting should define the primary goal to achieve towards the end of the sprint. It's important that stories in this sprint which do not lead to the success of the sprint are picked up later. This means that a sprint can contain critical, normal and low priority stories! A Drupal core sprint should at least be 2 months, we're still working with volunteers using their free time, and sometimes company time to make things better. At this point, issues can be assigned to a story which make sure we have a deliverable in which the PO, but in the end everyone is comfortable with. Once all is decided, we can start coding and try to make sure we keep up with what is planned. Change requests can occur - read, will happen -  but they should be put in our backlog and be picked up into the following sprint.

Moving stories to a sprint

Adding tasks to the Entity story

Adding tasks to the story

 

Tools

The screenshots above are taken from the great http://kanbantool.com/ website, which we introduced at Krimson - after a great learning process during my period at One Agency - use on a daily basis for clients, but also for our community work, whether it's maintaining or porting our Drupal modules, organising events etc. The project module already does an amazing job and I think with some really - relatively simple - changes we could make a more visualized and targeted picture of the path Drupal is taking. A board like I mentioned aboved for the Fedora Core release would be the great step. Being able to create meta-issues (stories) and reference other issues (tasks) with eachother is something I would gladly help to write patches for - in an agile fashion of course .. ;)

Will this work ?

To be honest, I think it could. But it won't be easy, but with the right spirit and good leadership, something like this could be achievable. Besides, how extremely cool would it be to tell we're the first community that would work like this - unless there are others, feel free to correct me. But in the end, just knowing what to expect in the next release would make a lot of people feel a lot more at ease.

AttachmentSize
backlog.png63.63 KB
tasks.png76.96 KB
sprintplanning.png66.68 KB

Comments

Submitted by David Lee on January 28, 2011 - 12:34

"A nice list like this would finally bring an end to the phrase "when it's ready" on the question when a new Drupal core sees the light."

Definitely agreed. At least we would have scientific estimation and progress to show everyone about project status, not just words without much infos, which I really happy if we can work in very professional manner like this :)

It also have potential to draw more people to get involved because they understand the status of the project, know the parts that need their skill, and feel comfortable to jump in at any moment when they feel like comfortably.

Also, it is fun to follow great thing we love being build and know how it progress, even normal users may even like to help in someway. If they don't have time to help, it will be easy for them to fund the project now because they know about progress, where the goal is and how much support needed to achieved that planned goal. Go to kickstarter.com for example.

I wish that DO would be able to hire all genius in our community to architect, engineer, work, fix crazy issues on core for 1,000-2,000 hours a years, which would drive the core development fast! If there's plan on this, I would love to fund for a few hours for sure!

Regards,
David Lee

Submitted by adrinux on January 28, 2011 - 13:57

Reminds me of reading about Google's chrome release approach: http://blog.chromium.org/2010/07/release-early-release-often.html

It would certainly be good to have a more regular release schedule. I suspect CVS has actually been holding us back. With the switch to git it will presumably become much easier to maintain and merge feature branches, and that should form a base for more agile development practices.

Head someone else ++ kanban a couple of weeks ago.

Submitted by translate.google.cn on October 24, 2014 - 08:28

Unquestionably consider that that you stated.
Your favourite reason appeared to be at the net the simplest thing
to take note of. I say to you, I certainly get irked at the same time
as folks think about issues that they plainly don't understand about.
You managed to hit the nail upon the highest as well as defined out the entire
thing without having side-effects , other people can take a signal.
Will likely be back to get more. Thanks

Add new comment

You are here