Sep 16 2018
Sep 16

Privileged to be given the opportunity by organisers at Drupal Europe to share Peace Through Prosperity‘s journey with the Drupal community. Thank you!

This was the third rendition of this talk since 2015, and in this time our charity, our work, progress of our beneficiaries and our learnings from it have come a long way.

What started as a one way street for transfer of frameworks, tools and strategies from digital transformation to effect societal transformation has gone full circle over past couple of years. Eight years into the journey and am now cross-pollinating approaches and ideas from societal transformation back into my work as a digital transformation coach and consultant.

Suppose it was a matter of time when I started seeing patterns from marginalised individuals and communities back into the work place with disengaged teams and individuals! But that’s for another post!

As mentioned in my session there are two call to actions to further Peace Through Prosperity’s journey to continue and scale our work…

  1. We are looking to partner with organisations on their Corporate Social Responsibility(CSR) programs – kindly reach out to your organisation’s CSR people and suggest sponsoring Peace Through Prosperity just as DropSolid currently do! We are looking to raise €30k with which we’d be able to engage with 800 micro-entrepreneurs in a 12 month period!
  2. Steal our stuff – connect us with your friends, customers and acquaintances in the charity sector, we would like for them to steal our open source products and programs, incorporate them in their existing work and we will support them in the task! it’s free!

My session at Drupal Europe coincided with Peace Through Prosperity running a mini-MBA for our third all female cohort in Lyari, Karachi! here’s 35+ micro-entrepreneurs from a marginalised community in Karachi stepping out of their comfort zone and graduating from the program! Well done ladies!

Interested to learn more? would you like to get involved? Cool! get in touch, you know how to find me!

And lastly I’d like to add a special mention for Druid from Finland! these folks brought along SWAG for kids! their T-shirts are an absolute hit with mine! #Thankyou

#DrupalEurope #Agile #Transformation #Society #Entrepreneurs #InternationalDevelopment

Apr 06 2018
Apr 06

This is the second rendition of this topic within the Drupal Community, the first time I shared my experiences and journey in this context was at Drupal Camp Sofia, in Bulgaria in 2015. In many respects this is quite a circle for me, I have fond memories of attending a Drupal meet-up in Utrecht (long way from home in Kent!) in 2012, receiving a very warm welcome by the local community at OneShoe’s very eclectic offices and meeting the personality that is Michel.

Fast forward six odd years and am stoked to be going back to Utrecht to share with a community that has been a source of inspiration for what we do at Peace Through Prosperity! I hope our work at Peace Through Prosperity serves to be a source of inspiration for my fellow Drupal community members and friends.

The session at DrupalJam 2018 has been recorded and shall add a link to the video as and when it is up. It also happens to be my eldest daughter Alvera’s second Drupal community event, first DrupalJam!! Well done! #SuperProudDad And last but not the least thank you to the DrupalJam team, to the attendees and my Acquia colleagues  Nicky Rutten and Maartje Sampers their time.

…………

Lastly, If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can followbroadcast or donate.

Peace Through Prosperity (PTP) works to improve the environment for peacebuilding by nurturing prosperity in conflict affected communities. We work to alleviate poverty and secure livelihoods through empowering micro-entrepreneurs with knowledge, skills and increasing their access to income and opportunities. We support small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.

Jul 17 2017
Jul 17

For those who aren’t familiar with the concept of Pattern-Lab (or a Pattern Library), it’s essentially a living style guide; a common tool in modern web development. At their most basic, they are continuously updated documents that help documenting common design styles for web components, bringing together the intended look & feel with the images and codes to build them.

I started to look into this idea around a year and half ago because I found that each time a new project started, I needed to redo much of the same styling work. Even worse, when the main project was still in development, it was hard to keep an eye on the minor changes that affected other projects, so they would quickly get out of sync with each other. There wasn’t a centralised place to store reusable components. Unfortunately, my initial attempt to push a “shared Pattern-lab” idea didn’t work too well because we had difficulties integrating with various tools and workflows across teams.

example living style guideExample of a living style guide

Now that our technology stacks at Comic Relief have matured, with a major shift to JavaScript frameworks and CI automation tools, the integration is getting much easier for shared styling libraries. Through inter-team collaboration we managed to make it work with our main development workflows (Drupal and non-Drupal) plus provide a way to using it for non-NPM projects. The result is a Pattern-Lab solution designed to be usable by both our internal and third party teams. We’ve also open sourced it so anyone else can benefit from it too!

Our Pattern-lab reduced duplication of effort as it’s ensured we have a library of reusable components that are common through all our main products. Additionally, this is giving us more consistency in our newer sites therefore reducing the time it takes for us to deliver. It also means that we now have a one-stop reference guide for both designers and developers working on all our projects.

The Features

To summarise, the Pattern-Lab is built on Node and using NPM, with the styles themselves being written in SASS and style guide generated by KSS. Every time a pull request is opened on Github, a preview version of the Pattern-lab is deployed to Netlify with Visual Regression tests run with Travis. Once code has passed review and been merged into the master branch, the latest release is automatically pushed to NPM and deployed to production by Concourse.

More details and documentation can be found here:
https://www.npmjs.com/package/@comicrelief/pattern-lab

Visual Regression

One stand out feature for me are the visual regression tests we put in place. These make sure that existing styles aren’t accidentally changed unintentionally when we add a style or make a breaking change. A big benefit of this is that now they’re integrated into our CI pipeline, if the tests fail, the code will not be released. It’s particularly important to make sure that we don’t break one product’s styles while trying to fix another!

Example visual regression reportexample of backstopJS visual regression test report

One of the potential future additions is to extend this to include automated accessibility checks. These would ensure we do our best to make all our sites fully accessible while we can also add unit test coverage reports so we can make sure we cover any areas that have been missed by our regression test suite.

Summary

For me, it’s taken a long time to get this far, but I’ve been really happy with how various teams were able to work together to make the idea into reality. We’re getting a lot of great use out of our Pattern Lab and I hope it helps you if you ever encounter any similar issues.

GitHub: https://github.com/comicrelief/pattern-lab
NPM: https://www.npmjs.com/package/@comicrelief/pattern-lab
CI Pipeline: https://ci.apps.comicrelief.com/teams/main/pipelines/pattern-lab

Share this:

Like this:

Like Loading...
Mar 07 2017
Mar 07

First and foremost thank you to all who made the time to attend my session on Empathy Driven Content Strategy at Drupal Camp London 2017. Thank you for sharing your time and perspectives.

This session was an evolution of two previous sessions:

There is a difference between walking in someone else’s footsteps and walking in their shoes!

‘Empathy Driven Content Strategy’ explores the transformation in content consumption, purpose, generation and how it impacts us. Looking at how empathy, touch points, sentiment analysis and emotional intelligence can be harnessed to create richer, more personalized experiences for people. With the purpose of motivating others to share the journey with us with content that is pertinent to and addresses their needs over the course of the journey.

We have seen how, over the past year empathy driven content, the use of sentiment analysis and knowing which touchpoint to invest in has played its role in both Brexit and the Trump campaigns. There are lessons behind their success for all regardless of which side of the campaign divide we may sit on.

As for getting started with Empathy maps, you can download examples and a blank canvas from the resources section below. Bear in mind the key takeaway is to ‘talk to people’ treat them as people first (customers later), to engage for the sake of understanding and keep our instinct to react in check… only when we understand can we respond.

Resources mentioned during the session:

Sentiment Analysis
Further reading

…………………..

Lastly, If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can follow, broadcast or donate.

Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in conflict affected geographies. We work to alleviate poverty, prevent radicalisation through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities. We support small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.

Peace Through Prosperity (PTP) is innovating social transformation design and delivery by using Agile frameworks to create and deliver low cost, immediate and lasting impact social development programs in ‘at risk’ communities.

Feb 12 2017
Feb 12

This is first of a series of blogs to support traditional project managers I am coaching. To help get their bearings in deep and murky waters of Agile projects and Scrum teams.

Before the scrum purists amongst you vehemently shake your heads or berate me on the title, consider being pragmatic. In the Professional Services world there is always a project manager to manage complexity and facilitate the Scrum team(s). My remit is to facilitate and empower the role to help the team, business and customers succeed, rather than debate its applicability and existence.

“Obey the principles without being bound by them.”
– Bruce Lee

I’ll be deep diving into a PM’s role in context to specific Scrum ceremonies in upcoming posts, however its seems apt to start with some health warnings.

Toxic Behaviour for a Scrum team

Toxic Behaviour for a Scrum team

A) This is not a guide for you to try and replace the Scrum master (you cannot) or the product owner (you cannot), or both! (you cannot). Nor is it a reference for you to justify imposing your will on the team (you cannot). It’s a guide to enable you to add ‘value’ to the ‘Scrum team’ and fulfill your purpose of managing risk on complex engagements.

B) Please don’t try to fake it till you make it! you will be caught out and the team will loose respect for you. if you don’t know, embrace not knowing and work to change that. Learn, up-skill, ask for help, do a pre-project retrospective on your own experience and discuss it with your Scrum master and/or Agile coach (if you have one). If you go in waving your strengths and weaknesses we will respect you for your courage and openness… they are part of our value system

C) Own your failures and reflect on them with the scrum master and/or an Agile coach. Don’t look for patsies, the team
will see through it and you will be called out on it. If you are failing, own it, be courageous and open, respect the knowledge and skills your Scrum team has (and you don’t) and in turn you will earn their respect. If you blame someone else for your shortcomings so that you can hide behind them you do not have the DNA to be in an agile environment. 

Agility, Scrum it’s a culture thing!

Agile Culture

Agile Culture

In order for you (a PM) to facilitate a Scrum team (yes your role is one of facilitation only) it is essential that you understand and embrace an agile culture, not just follow parts of a framework (Scrum). Toe-dipping is not going to work, you’re either committed or not.. its time to quit being a chicken and start living like a Pig

……………………

Lastly, If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can follow, broadcast or donate.

Peace Through Prosperity (PTP) works to improve the environment for peacebuilding by nurturing prosperity in conflict affected communities. We work to alleviate poverty and secure livelihoods through empowering micro-entrepreneurs with knowledge, skills and increasing their access to income and opportunities. We support small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.

Dec 01 2016
Dec 01

Startups and products can move faster than agencies that serve clients as there is no feedback loops and manual QA steps by an external authority that can halt a build going live.

One of the roundtable discussions that popped up this week while we’re all in Minsk is that agencies which practice Agile transparently as SystemSeed do see a common trade-off. CI/CD (Continuous Integration / Continuous Deployment) isn’t quite possible as long as you have manual QA and that lead time baked-in.

Non-Agile (or “Waterfall”) agencies can potentially supply work faster but without any insight by the client, inevitably then needing change requests which I’ve always visualised as the false economy of Waterfall as demonstrated here: 

image

Would the client prefer Waterfall+change requests and being kept in the dark throughout the development but all work is potentially delivered faster (and never in the final state), or would they prefer full transparency, having to check all story details, QA and sign off as well as multi-stakeholder oversight… in short - it can get complicated.

CI and CD isn’t truly possible when a manual review step is mandatory. Today we maintain a thorough manual QA by ourselves and our clients before deploy using a “standard” (feature branch -> dev -> stage -> production) devops process, where manual QA and automated test suites occur both at the feature branch level and just before deployment (Stage). Pantheon provides this hosting infrastructure and makes this simple as visualised below:

image

This week we brainstormed Blue & Green live environments which may allow for full Continuous Integration whereby deploys are automated whenever scripted tests pass, specifically without manual client sign off. What this does is add a fully live clone of the Production environment to the chain whereby new changes are always deployed out to the clone of live and at any time the system can be switched from pointing at the “Green” production environment, to the “Blue” clone or back again.

image

Assuming typical rollbacks are simple and databases are either in sync or both Green and Blue codebases link to a single DB, then this theory is well supported and could well be the future of devops. Especially when deploys are best made “immediately” and not the next morning or in times of low traffic.

In this case clients would be approving work already deployed to a production-ready environment which will be switched to as soon as their manual QA step is completed.

One argument made was that our Pantheon standard model allows for this in Stage already, we just need an automated process to push from Stage to Live once QA is passed. We’ll write more on this if our own processes move in this direction.

Sep 28 2016
Sep 28

Being accountable for the planning, execution, and delivery of a project is demanding. Managing people, facilitating communication, resolving conflict, and mitigating risk are prerequisites to completing on schedule, and within an agreed budget. Add to this the often unpredictable nature of these factors and it's little wonder that project managers feel a great burden of responsibility.

This article first appeared on OpenSource.com in September 2016.

Those suited to such a role are acutely aware of this responsibility and it's something they take on quite willingly. They perceive the role of a project manager as a guardian presiding over a project in order to protect it from failure. They are the last line of defense, willing to take the fall should something go wrong. It's an admirable position of leadership they seek to adopt, but the responsibilities attached to it can become overwhelming for even the most seasoned practitioners.

That's why I think they need to lose control.

Chasing waterfalls

Software-driven projects are rarely predictable. Initial requirements may prove difficult to implement, or, on reflection, prove to be the wrong approach. People are also fallible and can behave irrationally under pressure. Those project managers who fail to recognise these contributing factors and make allowances for them are simply battling the forces of nature that ultimately derail many projects.

In truth, failure is very likely an outcome at many stages of a project, so project managers' tendency to implement strategies for avoiding it when they feel ultimately responsible seems natural. It's easy for them to believe that the more predictable and orderly things are, the less likely it is that failure will befall their project. So preparing a detailed and prescriptive plan for the work required to complete the project seems like a good place to start.

The more traditional and predictive waterfall model is one safety net managers have used for many years as they seek greater levels of security. It's a time honoured approach, and it's an especially common theme for project managers involved in software development.

Faced with commercial pressures to meet deadlines and work within the bounds of restrictive procurement rules, project managers are also averse to change. They seek predictability and produce project artifacts like gantt charts, interface designs, and technical specifications that endeavour to precisely define project outcomes. They see them as a blueprint for success and use them as a weapon against anything that may threaten it.

But the more project managers seek certainty, the more they endeavour to control the factors that may affect it. Those that receive the most attention tend to be the people around them—those responsible for producing the outputs a project requires. Suddenly, strict boundaries constrain the project team, and managers encourage that team to avoid deviation. They direct all of the team's efforts to appeasing stakeholders expecting a predefined outcome.

Whist these behaviors may be understandable products of the pressure brought to bear on the project, the project manager creates an environment in which change is perceived as a highly disruptive occurrence. Thus, the reengineering of supposedly precise specifications and delays to a fixed schedule are unacceptable. Original plans become inflexible, and project teams are subject to close scrutiny in order to ensure overall compliance with it.

The much better alternative is to take a more agile, collaborative approach—where responsibility is distributed, failure is not feared, and change is recognised as a constant. It's a more common-sense approach that better accommodates the human factors that so strongly influence the success or failure of a project.

Begin with culture

Yet, project managers unaccustomed (or even unaware) of this alternative require a fundamental shift in mindset. Overcoming the desire for a prescriptive approach is not easy. Many are trapped in staid business environments where tradition dictates practice, and the appetite for change is low.

Fortunately, more managers are recognizing the appeal of Agile approaches to project delivery. And they're heavily promoting these across the business sector while adoption in government is strengthening. People acknowledge Agile approaches as a good way to increase value, foster a greater level of engagement with users, produce better products and services, and increase the well being of the teams who produce them.

The trend itself is good leverage for project managers who wish to move toward more Agile practices. Even small measures to become more agile can benefit their projects. They should better harness their leadership abilities to influence key stakeholders and managers. If possible, they should also seek to be more involved in the procurement process and negotiate a more Agile approach at this early stage of the project.

The key message for project managers seeking a change is that you need to work on developing the right mindset both for yourself and those around you. Facilitate more collaboration, empower individuals to take on more responsibility, and encourage your teams to become more self organised. Stop obsessing about plans or processes and guide your projects rather than trying to control them.

You might even find your team celebrating your next project as something enjoyable—not just something that's over.

Agile
Sep 18 2016
Sep 18

If you’re migrating from a different CMS platform, the advantages of Drupal 8 seem fairly clear. But what if you’re already on Drupal? There has been a lot of discussion in the Drupal community lately about upgrading to Drupal 8. When is the right time? Now that the contributed module landscape is looking pretty healthy, there aren’t many cases where I’d recommend going with Drupal 7 for a new project. However, as I’ve previously discussed on this blog, greenfield projects are fairly rare.

Future proofing

One of the strengths of an open source project like Drupal is the level of support from the community. Other people are testing your software, and helping to fix bugs that you might not have noticed. Drupal 7 will continue to be supported until Drupal 9 is released, which should be a while away yet. However, if your site is on Drupal 6, there are security implications of remaining on an unsupported version, and it would be wise to make plans to upgrade sooner rather than later, even with the option of long term support. While the level of support from the community will no longer be the same, sites built on older versions of Drupal won’t suddenly stop working, and there are still some Drupal 5 sites out there in the wild.

Technical debt

Most big systems could do with some refactoring. There’s always some code that people aren’t proud of, some decisions that were made under the pressure of a tight deadline, or just more modern ways of doing things.

An upgrade is a great opportunity to start with a blank piece of paper. Architectural decisions can be revisited, and Drupal 8’s improved APIs are ideal if you’re hoping to take a more microservices-oriented approach, rather than ending up with another MySQL monolith.

Drupal’s policy of backward incompatibility means that while you’re upgrading the CMS, you have the chance to refactor and improve the existing custom codebase (but don’t be suckered in by the tempting fallacy that you’ll be able to do a perfect refactoring).

There are no small changes

Don’t underestimate how big a job upgrading will be. At the very least, every custom module in the codebase will need to be rewritten for Drupal 8, and custom themes will need to be rebuilt using the Twig templating system. In a few cases, this will be a relatively trivial job, but the changes in Drupal 8 may mean that some modules will need to be rebuilt from the ground up. It isn’t just about development - you’ll need to factor in the time it will take to define requirements, not to mention testing and deployment. If it’s a big project, you may also need to juggle the maintenance of the existing codebase for some time, while working on the new version.

The sites that we tend to deal with at Capgemini are big. We work with large companies with complex requirements, a lot of third party integrations, and high traffic. In other words, it’s not just your standard brochureware, so we tend to have a lot of custom modules.

If it ain’t broke, don’t fix it

Given the fact that an upgrade is non-trivial, the question has to be asked - what business value will an upgrade bring? If all you’re doing is replacing a Drupal 7 site with a similar Drupal 8 site, is it really a good idea to spend a lot of time and money to build something that is identical, as far as the average end user can tell?

If the development team is focused on upgrading, will there be any bandwidth for bug fixes and improvements? An upgrade will almost certainly be a big investment - maybe that time, energy and money would be better spent on new features or incremental improvements that will bring tangible business value and can be delivered relatively quickly. Besides, some of the improvements in Drupal 8 core, such as improved authoring experience, are also available in the Drupal 7 contrib ecosystem.

On the other hand, it might make more sense to get the upgrade done now, and build those improvements on top of Drupal 8, especially if your existing codebase needs some TLC.

Another option (which we’ve done in the past for an upgrade from Drupal 6 to 7) is to incrementally upgrade the site, releasing parts of the new site as and when they’re ready.

The right approach depends on a range of factors, including how valuable your proposed improvements will be, how urgent they are, and how long an upgrade will take, which depends on how complex the site is.

The upside of an upgrade

Having said all of that, the reasons to upgrade to Drupal 8 are compelling. One big plus for Drupal 8 is the possibility of improved performance, especially for authenticated users, thanks to modern features like BigPipe. The improved authoring experience, accessibility and multilingual features that Drupal 8 brings will be especially valuable for larger organisations.

Not only that, improving Developer Experience (DX) was a big part of the community initiatives in building Drupal 8. Adopting Symfony components, migrating code to object-oriented structures, improving the APIs and a brand new configuration management system are all designed to improve developer productivity and code quality - after the initial learning curve. These improvements will encourage more of an engineering mindset, and drive modern development approaches. The net benefit will be more testable (and therefore more reliable) features, easier deployment and maintenance methods and increase speed of future change.

Decision time

There is no one-size-fits-all answer. Your organisation will need to consider its own situation and needs.

Where does upgrading the CMS version fit into the organisation’s wider digital roadmap? Is there a site redesign on the cards any time soon? What improvements are you hoping to make? What functionality are you looking to add? Does your site’s existing content strategy meet your needs? Is the solution architecture fit for your current and future purposes, or would it make sense to think about going headless?

In summary, while an upgrade will be a big investment, it may well be one that is worth making, especially if you’re planning major changes to your site in the near future.

If the requirements for your upgrade project are “build us the same as what we’ve got already, but with more modern technology” then it’s probably not going to be worth doing. Don’t upgrade to Drupal 8 just because it’s new and shiny. However, if you’re looking further forward and planning to build a solid foundation for future improvements then an upgrade could be a very valuable investment.

Jul 30 2016
Jul 30
‘I want to create a practical guide for product owners to facilitate them in writing acceptance criteria for user stories so that their output is of value to the scrum team’

You’ll find pages after pages describing what an acceptance criteria is and how to write a good one, what it should include or not, however this post takes a practical approach for Product Owners to follow. You’ll find post after post describing how product owners ought to use Gherkin script to develop/write an acceptance criteria, which in my opinion is not a practical approach, there are a few things wrong with that approach, a few come to mind right now:

a) not many product owners know Gherkin script and it’s unreasonable to expect them to adopt it when the team itself is better placed to translate their acceptance criteria into Gherkin. Doing so has its merits, the team has to analyse the acceptance criteria and develop Gherkin based test scripts from it, furthermore the product owner’s velocity for producing acceptance criteria is hugely improved as he/she is defining the fitness for purpose in a natural language.

b) calling out a product owner to write acceptance criteria in Gherkin or in a scripted fashion is prescriptive and goes against an agile approach, which is based on practicality and common sense. The Scrum master and team’s role is to facilitate the process, don’t assume your product owner can script!

Now that my preferred approach is set, lets dive into it:

For the newbies; acceptance criteria defines the intent of a user story, and is used to confirm if the user story is fit for purpose; the user story does what was intended, if so then the user story is complete. If you’re new to user stories please go here first.

Acceptance criteria must be developed by the product owner, it can be facilitated by the Scrum team but it’s responsibility must rest with the product owner.

The Scrum team’s expectations of the product owner to develop acceptance criteria must be realistic.

Things an acceptance criteria must cover (where relevant); usability, exceptions, desired output if the US is data driven, error handling, UX requirements, validations, any security and performance requirements as well as the function it’s seeking to validate.

Furthermore where applicable insist that the PO adds a wireframe or screen grab of the desired outcome for the user story. For those of you interested in a working example, there is one detailed out at the end of this post.

For those wondering when an AC needs to be in place…. It’s part of your *DoR (Definition of Ready) for the user story itself, your user story is not ready for technical decomposition or estimation without an acceptance criteria. 

For product owners looking for guidance to write acceptance criteria, a starter for 10:
  • Focus on the what and not the how – the team is not looking for a ‘solution’ from you as the product owner, just the ‘what’ is it that you are asking of the user story.
  • Keep the end user (and user acceptance testing) firmly in focus, it’s their point of view and value you are representing.
  • Develop acceptance criteria as a set of statements, each clearly stating a pass/fail outcome.
  • Specify both functional and non-functional requirements.
  • What are your security and performance requirements, need it be real time data display? Is the data sensitive?
  • Start with a sketch of what you are asking for, remember a picture paints a thousand words! 
  • There is no such thing as partial acceptance: either the acceptance criteria is met or it is not.
  • What is your user story? Think about what your want is? Can it be visually displayed? Is it related to display of data? Sketch out the different data entities (columns) you want to see, do you need to sort the display/view of data? Think it through in detail.
  • Is it a form to capture data? What data entities do you want captured? In what format? Think about what you don’t want in those fields (restricting input types), how would you validate the entries, what are the validation business rules?

This is a starting point for you and not a comprehensive list of do’s and don’ts, be pragmatic, and discuss the acceptance criteria with the Scrum team and your end user representatives; ‘conversation’ is a critical component of a user story and one that helps product owners bottom out the details of a user story’s acceptance criteria.

Your acceptance criteria must be acceptable to the Scrum team, if not then your acceptance criteria itself is not fit for purpose .

A tale from the trench

Our product owner’s requirement early on in the discovery stage was: ‘I want a login page to authenticate users on the site.’

So our user story would have been a simple one: ‘As a user I want to sign in to the site from a login page so that users can be authenticated.’

Then we began the deep dive conversation with our product owner; so what’s your acceptance criteria for the requirement?

and what we got was:

  • From on any page be able to access the login page via a sign in link.
  • On the site when I click the ‘sign-in’ link, I am re-directed to the login page where I can enter my email and password for authentication 
  • Upon successful login, I am re-directed to the homepage.
  • On the homepage my first name is displayed in the upper right hand corner along with the date and time of my last login.
  • If I enter an incorrect username and or password I should see an appropriate error message indicating my credentials are incorrect.
  • I should be able to retry authenticating myself three times before I am locked out of my account and must reset my password to unlock my account
  • My password needs to follow the company password policy for secure passwords
  • I must also see a link which allows me to re-set my password.
  • I must also see a link which allows me to register is i am a new user.

Can you spot the increased/emergent scope creep in the acceptance criteria as detailed by the product owner above?

Having seen the scope balloon we asked our product owner to sketch a wireframe for the login page, we were convinced there will be more that will emerge from a wireframe.

The wireframe sketched out by our product owner:

Login page wireframe

Login page wireframe

 

Can you spot further scope that has emerged from the wireframe? How often has the above played out for you and your team? 

We discussed the need for the additional user stories to capture the emergent scope  as well as the necessity of keeping the acceptance criteria for the original user story narrow to the user story itself. The conversation helped us identify additional user stories we needed to capture.

Having been through the exercise/discussions our product owner revised the acceptance criteria and the package looked like:

The User Story:

‘As a user I want to sign in to the site from a login page so that users can be authenticated.’

Its Acceptance Criteria:

  • On the sign-in page I can enter my email address and password and submit it for authentication.
  • My password needs to follow the company password policy for secure passwords
  • Upon successful login, I am re-directed to the homepage.
  • If I enter an incorrect username and or password I should see an appropriate error message indicating my credentials are incorrect.
  • I should be able to retry authenticating myself three times before I am locked out of my account and must reset my password to unlock my account.
  • I must also see a link which allows me to re-set my password.
  • I must also see a link which allows me to register is I am a new user.
  • I must see a CAPTCHA to protects the site against bots

The above user story and its acceptance criteria is independent, negotiable, valuable, estimable, small and testable within a single sprint, it is a user story and not an Epic that our product owner’s wireframe represented.

“Acceptance Criteria should not go beyond the scope of the user story, if so then additional user stories need to be captured that define the feature ‘wants’.” Well thought out acceptance criteria help us better understand the original scope, the emergent scope and create a contract with the product owner on the user story’s completeness and acceptability. * Thank you B for pointing out the typo. ……………..

Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in conflict affected geographies. PTP alleviates poverty, prevents radicalisation through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities. PTP supports small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.

PTP is innovating social transformation program design and delivery by using Agile frameworks to create and deliver low cost, immediate and lasting impact social development programs in ‘at risk’ communities.

Jun 23 2016
Jun 23

These days, it’s pretty rare that we build websites that aren’t some kind of redesign. Unless it’s a brand new company or project, the client usually has some sort of web presence already, and for one reason or another, they’ve decided to replace it with something shiny and new.

In an ideal world, the existing system has been built in a sensible way, with a sound content strategy and good separation of concerns, so all you need to do is re-skin it. In the Drupal world, this would normally mean a new theme, or if we’re still in our dream Zen Garden scenario, just some new CSS.

However, the reality is usually different. In my experience, redesigns are hardly ever just redesigns. When a business is considering significant changes to the website like some form of re-branding or refresh, it’s also an opportunity to think about changing the content, or the information architecture, or some aspects of the website functionality. After all, if you’re spending time and money changing how your website looks, you might as well try to improve the way it works while you’re at it.

So the chances are that your redesign project will need to change more than just the theme, but if you’re unlucky, someone somewhere further back along the chain has decided that it’s ‘just a re-skinning’, and therefore it should be a trivial job, which shouldn’t take long. In the worst case scenario, someone has given the client the impression that the site just needs a new coat of paint, but you’re actually inheriting some kind of nasty mess with unstable foundations that should really be fixed before you even think about changing how it looks. Incidentally, this is one reason why sales people should always consult with technical people who’ve seen under the bonnet of the system in question before agreeing prices on anything.

Even if the redesign is relatively straightforward from a technical point of view, perhaps it’s part of a wider rebranding, and there are associated campaigns whose dates are already expensively fixed, but thinking about the size of the website redesign project happened too late.

In other words, for whatever reason, it’s not unlikely that redesign projects will find themselves behind schedule, or over budget - what should you do in this situation? The received agile wisdom is that time and resources are fixed, so you need to flex on scope. But what’s the minimum viable product for a redesign? When you’ve got an existing product, how much of it do you need to rework before you put the new design live?

This is a question that I’m currently considering from a couple of angles. In the case of one of my personal projects, I’m upgrading an art gallery listings site from Drupal 6 to Drupal 8. The old site is the first big Drupal site I built, and is looking a little creaky in places. The design isn’t responsive, and the content editing experience leaves something to be desired. However, some of the contributed modules don’t have Drupal 8 versions yet, and I won’t have time to do the work involved to help get those modules ready, on top of the content migration, the new theme, having a full-time job and a family life, and all the rest of it.

In my day job, I’m working with a large multinational client on a set of sites where there’s no Drupal upgrade involved, but the suggested design does include some functional changes, so it isn’t just a re-theming. The difficulty here is that the client wants a broader scope of change than the timescales and budget allow.

When you’re in this situation, what can you do? As usual with interesting questions, the answer is ‘it depends’. Processes like impact mapping can help you to figure out the benefits that you get from your redesign. If you’ve looked at your burndown rates, and know that you’re not going to hit the deadline, what can you drop? Is the value that you gain from your redesign worth ditching any of the features that won’t be ready? To put it another way, how many of your existing features are worth keeping? A redesign can (and should) be an opportunity for a business to look at their content strategy and consider rationalising the site. If you’ve got a section on your site that isn’t adding any value, or isn’t getting any traffic, and the development team will need to spend time making it work in the new design, perhaps that’s a candidate for the chop?

We should also consider the Pareto principle when we’re structuring our development work, and start by working on the things that will get us most of the way there. This fits in with an important point made by scrum, which can sometimes get forgotten about: that each sprint should deliver “a potentially shippable increment”. In this context, I would interpret this to mean that we should make sure that the site as a whole doesn’t look broken, and then we can layer on the fancy bits afterwards, similar to a progressive enhancement approach to dealing with older browsers. If you aren’t sure whether you’ll have time to get everything done, don’t spend an excessive amount of time polishing one section of the site to the detriment of basic layout and styling that will make the whole site look reasonably good.

Starting with a style guide can help give you a solid foundation to build upon, by enabling you to make sure that all the components on the site look presentable. You can then test those components in their real contexts. If you’ve done any kind of content audit (and somebody really should have done), you should have a good idea of the variety of pages you’ve got. At the very least, your CMS should help you to know what types of content you have, so that you can take a sample set of pages of each content type or layout type, and you’ll be able to validate that they look good enough, whatever that means in your context.

There is another option, though. You don’t have to deliver all the change at once. Can you (and should you) do a partial go-live with a redesign? Depending on how radical the redesign is, the attitudes to change and continuous delivery within your organisation and client, and the technology stack involved, it may make sense to deliver changes incrementally. In other words, put the new sections of the site live as they’re ready, and keep serving the old bits from the existing system. There may be brand consistency, user experience, and content management process reasons why you might not want to do this, but it is an option to consider, and it can work.

On one previous project, we were carrying out a simultaneous redesign and Drupal 6 to 7 upgrade, and we were able to split traffic between the old site and the new one. It made things a little bit more complicated in terms of handling user sessions, but it did give the client the freedom to decide when they thought we had enough of the new site for them to put it live. In the end, they decided that the answer was ‘almost all of it’.

So what’s the way forward?

In the case of my art gallery listings site, the redesign itself has a clear value, and with Drupal 6 being unsupported, I need to get the site onto Drupal 8 sooner rather than later. There’s definitely a point that will come fairly soon, even if I don’t get to spend as long as I’d like working on it, where the user experience will be improved by the new site, even though some of the functionality from the old site isn’t there, and isn’t likely to be ready for a while. I’m my own client on that project, so I’m tempted to just put the redesign live anyway.

In the case of my client, there are decisions to be made about which of the new features need to be included in the redesign. De-scoping some of the more complex changes will bring the project back into the realm of being a re-theming, the functional changes can go into subsequent releases, and hopefully we’ll hit the deadline.

A final point that I’d like to make is that we shouldn’t fall into the trap of thinking of redesigns as big-bang events that sit outside the day-to-day running of a site. Similarly, if you’re thinking about painting your house, you should also think about whether you also need to fix the roof, and when you’re going to schedule the cleaning. Once the painting is done, you’ll still be living there, and you’ll have the opportunity to do other jobs if and when you have the time, energy, and money to do so.

Along with software upgrades, redesigns should be considered as part of a business’s long-term strategy, and they should be just one part of a plan to keep making improvements through continuous delivery.

Nov 28 2015
Nov 28

logo_small_sx_1logo_small_sx_1 The keynote at DrupalCamp Bulgaria was planned to be left field from the get go, however it went a little further out after Paris came under attack on the night of the 13th of November 2015.

#JeSuiBaghdad #JeSuiParis #JeSuiBeirut #JeSuiChibok #JeSuiKarachi #JeSuiMadrid #JeSuiDamascus #JeSuiAnkara #JeSuiLondon Dalai Lama Quote 2015Dalai Lama Quote 2015 #JeSuiMali the list goes on, but other than on the bench solidarity what are we doing as individuals, as a community to facilitate and help build a better safer, cohesive and a pluralist society?

As a FOSS community we are constantly talking of give-back but are we engaged enough?

How could we take the strengths and learnings that make us a successful tech community to wider non tech audiences with a view of creating social transformation that addresses the needs of our societies in these turbulent times. What can we learn from the transformation FOSS and the Cloud has had on our ecosystem as technologists and how can we export that beyond tech to heal and build a stronger society?

I have more questions for discussions than answers however there is an inflight and successful start made by Peace Through Prosperity using Agile, Open source and Cloud to deliver social transformation programs that could be a starting point for the Drupal community to engage with in their own geographies. The open source component of this program is in development and work in progress can be seen here, if you’d like to contribute and #GiveBack beyond our bubble please get in touch over Twitter or Linkedin.

Links shared within the keynote slides:

The presentation from the keynote:

Open Source and Cloud Beyond tech from Kubair Shirazee

One more option to look on her packing at it levitra vardenafil it of course to take not so simply because a form another and there is a wish to hold in hand her not so strongly. You can carry by me on a wide field.

Nov 20 2015
Nov 20

More a log than a guide, but you get the idea! its a lengthy log this week, a lot got undone, done and then some. Backlog for the week:
  • Fonts
  • Contact Form (customise it)
  • Translations (Lingotek)  
  • Take the site online 
  • Toy around with Drush
Not part of the backlog, decided to update core, followed the instructions to the letter, used Drush and broke the site completely! ha! ‘A little learning is a dangerous thing; drink deep, or taste not the Pierian spring’ … and yes did not back it up did see Drush had created a back up but have failed to locate it! was going to take it online anyhow, so decided to rebuild on Acquia CloudSite folder on DT02Site folder on DT02 Would be interesting to see how long it takes to rebuild it! good organisation should make the task a tad bit easier! Revisions made to node/1 were not in the .txt file, extracted them from node_revision_body from the database (a little learning can be a useful thing too) – a small win on a rough day!
  • Logged into Acquia Cloud, spun up a free subscription, installed D8.rc3, and got cracking! 
  • Only downer is can’t add contrib modules without figuring out how to SFTP, or using Drush. For now staying clear of Drush! fear of the terminal is back!
  • Set up path aliases, was a quick and easy introduction and gets rid of the node/n in the address bar, of course good for SEO and all that jazz.
  • I know there is an easier way to justify text alignment via CSS but that’s going to take some time to get to grips with so taking the long but short cut with HTML to <p style=”text-align:justify”>.
  • It was a good day, a forced refresher on getting sh*t done and it took less than 2 hours to get the site back on track a little ahead of the previous version too! wooHoo! 
  • Tested the contact form but it won’t work, a bit of digging around and seems SMTP Authentication Support needs to be installed, am after a quick win today, decided to install and toy with Lingotek instead.
  • Dang it! can not upload to Acquia Dev Cloud, dug around, need SFTP or SSH access, ok set up my SSH Public Key, downloaded FileZilla, followed the instructions and nada! time to put the fear of thescreen-grab-lingotekscreen-grab-lingotek terminal behind me (again) bounced around from page to page but finally got in WooHoo! installed LingoTek in the wrong place Blistering Barnacles!
  • Tried to uninstall LingoTek, could not (commands I’m seeing online don’t work for me), Ok so the next best thing is to install LingoTek in the Dev folder but nothing in the sites folder! Bizarre! or may be not!
  • Anyway reading up on Drush and installing modules on Acquia Cloud and WTF! there is aenable live devenable live dev simpler way to do so! Why is this nugget buried so deep! Evidently all I needs to do is go to my Sites/Cloud and ‘Enable Live Development‘ 
  • That done time to check out LingoTek, copy link address, install, enable, wait, enable dependencies, enable job done! Lingotek Translation itself, lemon squeezy!

LIngo Tek grab 04LIngo Tek grab 04

  • Ending day 2 on a colossal WIN, I have translations for basic pages and articles in Arabic, Bulgarian, French, Hindi, Spanish and Urdu, the main and footer menus are not translated as yet, neither do I have language select buttons/icons enabled, to access the languages I have to go by the language code in the URL and its not perfect I still need our Peace Through Prosperity volunteers to check and edit  multilingual content but they’ll  have less to do. LingoTek kicks ass!
  • Time to take on the font challenge!
  • Noticed whilst on my local environment I was having problems installing modules, kept getting error messages that told me nothing other than it’s an error (FFS!), however haven’t been getting many of those on the Cloud.
  • AnyHoo, for fonts decided on Google Webfont Loader API, comes highly recommended by @Dakku and has a D8 recommended release out too, so what could go wrong. Installed, enabling took ages and it works but… there are only two font added to the library of fonts  (not exactly a library!), all a bit anti-climatic!
  • Not quite what I expected, font attempt five or is it six now is a fail! uninstalled the Google Webfoot Loader API and am going to start exploring the CSS route one of these days. 
  • Its Menu translation day – why hasn’t LingoTek got an automated workflow for menu item translations? got it done but what a pain! suggested improvement for LingoTek: have multiple language translations for a menu item on the same page please! a lot of unnecessary back and forth in the workflow.
  • Decided to spend time on CSS so that I need not rely on modules to change fonts and to get the menu translations in place between day 4 and 5, SMTP set up and the contact form will have to wait its seems a bit complicated and will need help on this in the know, as a starter have bookmarked CSS architecture (for Drupal 8) and Drupal 8 Theming Fundamentals to my reading list.
Its a big day, the WIP site gets opened up for demo on the blog!  Retro time!
  • Fonts – tackled again, failed, avoided (need dragon glass to tackle this one)
  • Contact Form (customise it)
  • Translations (Lingotek)
  • Take the site online
  • Toy around with Drush
  • Backlog grooming
..and disaster strikes! somehow managed to lock myself out! can’t recall the password! dang it! it was such an awesome run! need help on this, tried SSH, can SSH but getting access denied for getting DB backups and hesitant to do too much using Drush, remember day 1’s lesson well. Added @Dakku to the Site ’Team’ on Acquia Cloud and its all good.  Week three has been an epic adventure! am clearly trying to run before I can walk but am finding the platform is coaxing me to do so! what little surface I have scratched has opened up a whole bunch of stuff to add to the open social backlog and am getting pretty confident quite a bit of it could be handled by myself! yes humility is a must have EM trait!. Week four will start with an upgrade to Drupal 8.0.0 WooHoo…! in the mean time feast on this…..in seven languages! Open Social Transformation PTP03Open Social Transformation PTP03

One more option to look on her packing at it levitra vardenafil it of course to take not so simply because a form another and there is a wish to hold in hand her not so strongly. You can carry by me on a wide field.

Nov 12 2015
Nov 12

More a log than a guide, but you get the idea! Day 1’s timebox went on user stories and sprint goals (1 week sprints btw); this sprint’s goals are;
  • main menu,
  • footer menu,
  • social (Twitter) feed
  • static content for pages
  • font face
  • Favicon
The allocated time b/w days 2 and 5 are 3 hours in total, so lets see how I fare this week. Started with aesthetics in the hope they’d be the easy wins. 
  • Changing font face – fail: Googled and it appears all I need to do is change the font type in a style.css filesite building D8 font issuesite building D8 font issue , first fail was there is no style.css in the Bartik components folder, did find font types in the elements.css file, edited it, added Arial and nada!
    Went on a module hunt, found font-your-face – installed, did not work, looked up the documentation and does not show up under admin/config/settings/user interface. packing in on the should’ve been an easy win and moving to the next item on my backlog.
  • Favicon success – downloaded Favicon, installed and it has a configure link under extends, first module I’ve come across that links its settings/config page from the module description link from the Extends page (good UX, thank you dave-reid). Initially the .ico file upload didn’t work, thought it might be a cache issue, cleared cache (mysite/admin/config/development/performance) did not work, decided to try renaming the file name and wooHoo! it works. Decided to call it a day with a small win.
Bartik Block RegionsBartik Block Regions

Newbie tip bulbbulb

I took a screen grab of ‘Bartik’s block regions demonstration’, printed it and pinned it to the wall and added it to desktop 2 as a wallpaper – am sure over time I’ll know whats where but for the time being its proving to be a good idea.

WooHoo, its a Saturday and though still working on a project (not really a weekend) am going to take some out for this.
  • Twitter feeds turned out lemon squeesy, with a work around, Twitter widget in a block instead of waiting for maintainers to sort their D8 modules out, thanks Dakku. Five mins into it and job’s done, there is a now a Twitter feed widget on the site! WooHoo! got carried away added a Twitter search box on #peacebuilding and #entrepreneurship, two big wins in less than 10 mins, am on a roll!
  • Next up was Social sharing, searched selected Easy Social, downloaded, installed, read the documentation, fail…. another 10 minutes invested into it… fail fail! should have quit on a win but anyhow failed fast enough to have some time to spare on other backlog items. 
  • So over to Footer menu it is. Added a bunch of menu links but not quite what I had in mind: 
Footer 001Footer 001 Got undone on finding any attributes to the menu setup that allows for external links to be opened in a new window, dug around and found its not possible without a module to manage menu attributes, It took a little bit of time, found one that is D8 ready, and guess what… does not work! fail! Went through the Readme file nothing under admin/configurations tried getting to the  setting using /admin/config/user-interface/extlink and nada! blistering barnacles! Back on the footer menu fumbled around and wooHoo that’s more like it, now to split them out: Footer 0020Footer 0020 Am wondering if I am going about searching for modules the wrong way round for it seems like an awful waste of time trawling through different contrib modules trying to see if they are D-8 ready or not, thought there is this site that lists the status of the top 100 contrib modules it doesn’t cover all of them and when using Google the ones that do turn up are those on D.O and there is just so much noise there! All the contrib modules I have installed and all of the ones that tell me in their Readme file that I will find config links under Admin/configurations –  none have turned up on that page, and when I have tried getting to the  setting using /admin/config/modulename/settings have had no joy either! this pattern suggests something is going wrong with my install! maybe!?” cleared cache too and still nada! more blistering barnacles!! I had a partial win with Footer Menu blocks, am going to take that and come back to this another day.

Its day 4, its shorter, need to stay focused on getting a win.. need it today.

  • Decided to go with the contact form, was easy enough apart from the fact that I could not figure out how to edit the tables for the default form, that’s a ‘nice to have’ so stuck to the ‘must have’ scope and extended the default form as required with custom fields. It was simple, took a bit of toying around but did not need to reach out or Google any how to’s. its a good win, was quick enough so decided to take on a couple of one more task.
  • #OpCleanup; decided am going to clean up all these modules that don’t work, err no uninstall button, its Google to the rescue, a little strange that to uninstall the modules I have to go here: /admin/modules/uninstall and there is no link to it from the extend page! may be I am missing something here. With another win and on a roll decided to look into this unexpected error I’ve been getting intermittently when installing contrib modules:
  • Found a page on D.O on the issue and responded to by a colleague! hello Eric! but the details’way too technical for my current knowhow or lack of! am going to wait till 19th Nov, assuming Dev Desktop will see an update the same day and reinstall Drupal 8 and see if that changes anything, failing that will be badgering some of my TA colleagues.
Was a washout! not enough hours in the day to fit everything! quick retro;
  • main menu,
  • footer menu,
  • social (Twitter) feed,
  • static content for pages,
  • font face
  • Favicon

Did not get to put in anymore than 2 hours over the week, got to >80% of my backlog, broke through last week’s blocker, got stuck on something allegedly trivial, that’s a good week! Looking forward to week 3, I’ll be jumping in font first! 

Peace Through Prosperity Open Transformation ProjectPeace Through Prosperity Open Transformation Project

End of week 2 this is where I am at, not bad!

One more option to look on her packing at it levitra vardenafil it of course to take not so simply because a form another and there is a wish to hold in hand her not so strongly. You can carry by me on a wide field.

Nov 05 2015
Nov 05

More a log than a guide, but you get the idea! Many a weeks before Day 1! started putting a backlog together, the site is for an Open Social Transformation project, its open sourcing the materials designed and developed for Peace Through Prosperity’s social transformation programs that have had epic results so far. The aim is to make the materials and processes available under a creative commons license for communities across the third rock to use and transform for the better, from the ground up.
  • Theme-Library-D8-Theme-install-failTheme-Library-D8-Theme-install-fail 25th Oct 2015 installed Acquia Dev Desktop and got cracking, first impressions; intuitive, a bit like WordPress thats a plus! the learning curve wont be as steep as I had suspected it might be.
  • Bartik looks dull and boring, decided to go on a Theme hunt.
  • Downloaded Zircon – installed, set as default, does not work,
  • Downloaded Adaptive – installed, needs something called AT Core, searched, and installed, set as default, does not work,
  • Back to google, found MAYO, looks nice, installed, does not work,
  • Am 30 mins into my hunt for a theme that looks good and works and am nearing to an OFT moment.
  • Another 5 mins and reached OFT moment.
  • Decided to go with Bartik, into settings and am determined to make this look nice, wasn’t that hard actually! 
  • But need to clean up my Theme library! this is what it looks like after 35 mins.
Drupal-8-engagement-manager-suite-building-guide-001Drupal-8-engagement-manager-suite-building-guide-001 Five minutes of fiddling about in Bartik’s settings and moving the Login Box to Footer 5 (not disabling it for now) this is what my home page looks like! Not bad for a newbie to Drupal… the fruits of less than an hour’s labour and it is responsive out of the box with zero effort!  OK that’s too much excitement for the day, going to quit while I am ahead and get back to it in a few days. A few days later… Decided to hit the deep end before creating my pages and static content, time to add some fancy Blocks, getting the @bringptp Twitter feed on the home page would be epic! The search began for a Twitter module for D8, two choices, Alex Finnarn’s Drupal-twitter-feed and the Twitter Module off D.O – hit a glitch with both, with the Finnarn’s Drupal-twitter-feed module off GIT the challenge became lack of documentation, once set up, had no way to figure out what to do with it as a newbie. With the Twitter Module installing the Entity API became a pain, first things first Entity API is part of D8 Core WTF! kept getting “entity-8.x-1.x-dev.tar.gz does not contain any .info.yml files error”,  looked into the error and got lost in the conversations about it on D.O! whoosh over my head! It was time to call in the big guns, time to reach out to Dakku for help figuring this out. As for the rest of today’s timebox will be getting the pages and content in shape to give the site some semblance of a site prior to diving into the Lingotek module. On reflection today was less frustrating, packed up when I hit a blocker, started finishing and stopped starting, am practising what I preach.  Met up with Dakku and made use of the lunch hour to get some help with the Twitter modules I installed and failed to get them working, turns out its the modules and not my lack of perseverance! Alex Finnarn’s Drupal-twitter-feed module doesn’t show up on the configurations page as the limited documentation suggests it should, so ditched that and moved to the Twitter Module. Got introduced to the issues queue for modules and how to find answers to issues I am having that others have faced, reported and found solutions to, turns out there is an issue with the module as reported on the issues queue, the module has a dependency on Entity API stated in the twitter.info.yml which shouldn’t be there, this dependency prevents the module being installed. Anyway decided I’ll get to Twitter feeds in a Block at a later date once its been patched – which by the way is under way. Dakku on it, submitted a patch that is pending review. With Twitter feeds out for the time being I got a short introduction to Drush and how to install modules using it, haven’t quite got my head around it yet but the fear of the Terminal is slowly giving way to possibilities of being able to use the command line to get sh*t done. Drupal-8-engagement-manager-suite-building-guide-003Drupal-8-engagement-manager-suite-building-guide-003 Back to building up my site, first things first the ‘read more’ link on the home page is getting real annoying, I need the entire content of my page displayed and not a snippet of it, late night IMing for help Dakku pointed me to ‘admin/config/system/site-information’ should have seen that! (mental note to explore more).  Menu links added, with the home page taking shape keen to get some play time with Blocks, a bit of toing and froing got to grips with creating custom blocks and wooHoo! rusty HTML knowledge’s coming back and is handy too. Added two custom blocks: Gofundme and a Vimeo widget blocks and it looks Epic! Still have some time to spare, decided to go social, and got pointed to the Social Media Links module by Dakku, looks awesome but came undone after installation! opened up the modules folder, had a look at the Readme file but when I go to ‘/admin/structure/block/manage/social_media_links/social-media-links/configure’ there is ‘no page found’ dang it! so close so close! must pack it in and get back to this in a couple of day.  Even if I say so my self am chuffed with what has been possible over 3-4 hours spread over a week, next up getting the Social Media Links module to work and then to Lingotek before I start exploring Organic Groups, which will have to be de-prioritised since Organic Groups Module is not ported to Drupal 8 as yet.

One more option to look on her packing at it levitra vardenafil it of course to take not so simply because a form another and there is a wish to hold in hand her not so strongly. You can carry by me on a wide field.

Aug 11 2015
Aug 11

I recently attained the Certified Scrum Professional (CSP) certification and found the process a good opportunity to reflect on what led me to Scrum. It was also a chance to take pause and consider our industry approach to project management.

Over many years I have seen teams wrangle with various methodologies based on traditional approaches to project management. Hybrid models based on the PMBOK framework or the Prince2 model were most prevalent. The common thread was always a very structured Waterfall based approach to projects.

As the Web industry and associated technologies have gained maturity there has been a trend towards a more agile approach. The methods used to define and deliver applicable functionality have changed as projects become more product focussed. At PreviousNext we recognised the need to adapt our approach some years ago and chose to adopt Scrum as our standard model for project delivery within our Drupal development and design teams.

We have since learned a great deal about making the transition to a more agile approach. Both structural and cultural change are necessary to become successful proponents of Scrum, but to achieve real success you need to foster an agile mindset within your team. Education is a key factor in this and all members of the PreviousNext team - developers, designers and client service managers - have been formally certified as Scrum Masters.

An equally important factor is how well your clients comprehend the nature of an agile engagement. Training Product Owners and client stakeholders on the fundamentals of Scrum needs to be complemented with ongoing coaching and mentoring throughout a project. It’s a very new and challenging concept for many, but taking an educative approach can lead to an enlightening and trust building experience that benefits everyone.

Ultimately it’s important to appreciate that adapting to a fundamentally different ethos takes time. It requires perseverance to overcome the challenges that organisations face when making a significant change to their existing model. The positive impact on client relationships and project outcomes make the adoption of an agile approach a worthwhile journey to embark on.

As more organisations come to appreciate the benefits, the uptake of Agile will continue to grow. The recent formation of the Digital Transformation Office (DTO) and establishment of a Digital Service Standard focussed on an agile and iterative approach to the development of digital services is a significant milestone.

This new Australian Government model of digital service delivery is an encouraging development and validates the work we have invested in our own approach. We look forward to supporting the DTO’s initiatives through knowledge sharing and Agile leadership as organisations across government and the wider industry adopt it as their own standard.

Agile Scrum
Feb 26 2015
Feb 26

‹�]�r�’�-U�`z#’k/’%�”(�|I�N�”=��X�H�5œ™�E4��]�,~��‘”L9��s��‰�\�F��k�y������z&���;�>�cY��c��™8x‹WJ�3���&<�O5�[?>�Q��”��–U�x�T�p�Š–*>ب�1�;��0z�|{B…2�˴,�Jo��ƒ_3•HaOe�dP���|t�_�Ԡv�yDIM؁Ÿ(�“L��tme�‹�•�‰�N�Fi(=�D�Bq��n,v��}�s��n�w„t�I N�� |�‡8����‘��q�$'g�ŸE�qm���*�TQ���~Jg����4‰��—���Y�F���^K� f��c™��qG��}��…ˆ”7�…Q0351��xP›&I��t&�p��I�����z��E�8Yx*�*%‹"K��c�qM�”��A ]^�9Ÿ���H�Q–��+W=i�i�9�25G&����Du&��h$cup������7=��ǧ�O�ŸW�Ng�����g��B�>>���_Ÿ��q"��hk^�����2…*“Cz‰Š|�?�@†•��Dq|�Yd ����Zk‡���*��ʬ�e��‰��ip$~P��l��Q��<���z�$˜�0��[t�6U�%�w;o��p��FVB X��=�JK2�’��2�x�9�‰2w�›y{8�,x瞩„d�v�F3��ȫ�5co:o:q{N�M‡�k�C�7��s���p�M�֪�)Tk‡>�k-f���kp6—.S]��7�2\Ÿ�2ZzsW�� ܵg�‡�7���m�֮hrom��>ˣ![�–��˜��!›�K�ƒQێ`O�3O�X4j��!�Z����D%O�_�Ovv�o�ڮSkE*I#���qڀ�9�5œ6y֠�$� ��P 4t��Š���8�\�A0cONjƒ�@R�ŒH�,‰0�q̞q= �����?h�<�����a��mu›-��OaE}��l{�Ÿ$�“=���oB�h��Z�;ƒ�C�}N#LT�ƒ���5�d��m6�wzW�L� 25��<��$1�V[#j��‹/�����F� h�‰V�˜���O���4���8nMˆr�Œcwz��a~�`’”)��ݼO_��Dƒ;=�E�H�“p� Wœ��r�.��šikڤyQ��ƤJ�B���Gm�8�x’n0��G�մF -?�h��2��š���š-��,9;“�G‰$‘�”5j�o�›�v5‡�‹��?Q�V‰yLV�$�+4t�{rFe����jB�˜3z����ǫָ]š�T���������Œ�‚�A��[�E/�T�ټjh[�r;%i]c�šd �Nf���2�>��}�;�†E‹_™AFǍ�W�\Ÿf��ƒ�8K?�Q1��ƒ�œ�V<•`k]�T‘K�‹�šU384Z“�9q��Šv�p9“�|—gIϝ���m���™DAJ8r•Ÿ�‰�r��� ��^D/u E�m��@!N�B��Ɓ@’rƝ4�^�•�,�-l�{��z����z�����M�T‡ ֫�`…�w* !†��2�RŒB�1„���9gu�����2—7:�"ŠŠ�—ݸ= ‚‰�B�Fb"…HE,T�Y_�Ygš_�j�f�•w��*Z˜_™w�{��n�‚}�v�™;‰`-��{9ˣ�ў����a„Nr�P'�� [F}�ɯ�Ÿ�G�N��>{z۠�h,��7*u�*NֵZ�֭o�ؐT‰@› tNDy�…‘��›>�ϧJ�h8�ڍ f�k-j‚X”B�%X^�h~&SeED��˜4PaF�J*$;�6�‡��\–‘�‹>ůBw��9Fx6e2]l�b�{LW#�‚�,���• |��o���`�RNa��u�F…ƒ�ƒ������‚5M”��n‘}W!z�s����P�mW‰F�(H�$� ��–��M•�c?�[email protected]���b+v����1y�#q�aˆv�x�Œj…(�y�p��0�Ey��†�‹~�Ÿ��:ƒ�2�H…����q�@��6�Q‘�EŮ�K�����…8Ÿ� ��*~V�q�^\�‰Z�_MQd��9���“��秿mJx�_�lj�(��mZ�)J�F���5M�Ш;�%a‚7�dX�y:���Rš�FqqR�$cJ-F‚s�v:�.���][�‡���n�”����(\oŠ �*����„~‚›(�J�~u���q.�‘�&�)–^‡3�=�42�c˜c�uw:�…����y��„5�‚�I;�*�ֿ���‚c��†�‚�ѥd�"�|e'0�T�Bu&`…��ˆ‰Œ�h�n�����6c��I�`�&�^9`��?Pd��ƒ���k�e�”�ˆ�����œ]Q�����}@b�˜���=Ǡ �ƒB�_�A?\Ǣ�)Kתj‘�p�'��ŒD2�{/��BG���‘Œ�†��PKS�7�MŠ� •a:� �8th$a|"�O R†�Œ—W�™ei'pr‡�?9–�“š�6�“����†��3�e=�-zV�'/��v�m���(��K_�Z�9��ˆׁ}"�ZT�LVL ��”�*p�<"Q����8b�:3�‡(?|�C:�[�-†a��Œ��nji��cP��߭ �]g.��™MI-=�2:&N�‘�0`:"�#pkO)�3 �H�Ǟ)a}�4�8j^���“3&~���\��ô“�U�=X mb�[M”�4p0�l�L*NG3� –�j��n–r)�TU�wH��}�́�mE‡}�TG�;‘Z��Dػ[email protected]�)}��Y64�nhԭ‘EXO��‰�F!\T"DF.���|�yJ!w1=–š#f�R�Q�$66B'?��h��U =2•CX�™�'‹��c�6�,�BX�h�mE�D‡X��r܁��l���‡C��Im”MVf–96%��3D��La��Œ��R3›�.�e�)� �ɭ� š�Š�T�:e}`w��#����i��o�\[�N٩K�‹ �H�j';p•�‘���•a�������n��-�p �š�/�)��<*q��pY�Š����� ��:‚QcX‘›—<…A› �A(�L��A,�> MT™�I-,�"�w˜b�C9�JTgi‰��7���’•�‰œHc� )_���šHY���(�ƒ`����&•��rK�i� 0X�3��Vk��m/vM�恱h���P› �pŸ͎���›��V�f��‚�F–|żU^>]F?)裂��5ŠRrt�-– �)=��aZ��D�J�V�3›V��u�%‡/%?œF�9��p%q)�6��oW�� ™‰˜X�O�*NE†7��2�W�+�›‘%#��–�]Œ��Š[K~�]�Dc�Vu'G�ͪϝI�9��r�'�“�I��›:K�t���ƒ:� �k�� ƒ�U�qx�[email protected]�thƒ—�m��~M��ƒ=s �/>�����9�z�‡�h�^�}(Š�<�„�zŒ�ͬ�2F���’�m��-Wf�J��“�N`��+k•›����igΫ™�Y�„�e4��2†#8gX���Nš›++�Z��eM���šeO�)2�Œ�)�&`[��"�#э=9“#I'S—™�—^™���Wxc�CC�1‚C�h˜P R‚�Sr�܍)���†�}�… �K'�.��+�j[s��\8�2T��d�sWK�‰�Ÿ�ˆ��“����������›><Š[���YL‚RJd|�}„>Ho,$™`��ԝq�œp�ˆ%诧LQ�!B{�#�Fu�����{/�J�b����� p%^��yh(�1E•d����Pn��’3�‚Ql��›����\Š�ݤ �i4��bKZ#�wD�$�”�g!aD�(�$���� �H�c[R'�(H'S‹ ���‚�/A͐6�{k��BU,A7�By[<3FŠz*…���“j‰��`BN�‹�B�5L#6Q�Ÿ(���A›Z•hGB�A%zվ�SŠ PC���HAi�7�)�„f�|j&�.wK�,˜�v�sfB�,c7O���V)@“8‰�w ��ߧ•��Xrj�"™XeIX,k�™�[�����–E*��%+�r�dZЬ�D�†��3DKj��’�ǁ,��y�Pmst pP‘h"Lg��Œ�x!�.„5����b�_1��DG?(�z|4$“�i��l—d\[‚��\�ZjSšXš(m~�m�Q��;K��tŒ6�P�’O�F\��’�Z5(j6���/0 Sq:�(���G/Xʳ…�����!�]�4�#]˜����x�RҦ�_���U�!d�,��h�9�\]��t����/bV�J춬�Ÿ?�8)��3 �[*�[�nW�R/q=��H0�œ”g‚d���o<+H�6P™����h��z(2“�V���…9��– �D'›ivA/bw„–��j�S�H�Aa9�wŒ!A�Ӑ��7ci=�dB4��5/„œ<�B j?�ˆ…8� �[email protected]`ˆ�i$0�JG�d]x–C[Yš˜YjA��—�8b\Ÿci“b�ר� N�S�‡kš���^ŠҮO�ˆ�‰†]�[email protected]…�9Š�,�…�‰m–‘�œ$/y��ˆQ�k��-�J^ a�;���2���‚| K!�fb�—l�1�ȭq4�‡�$r��cƒ9OIְ��d�ŠЦn �NSH�Œ�T^�2�…�vH�>T6$e�”†���b�]*mu���Y�—z��'�S_�E<�@›�!6[P‡‘R�$š��%dŒ{ lŠ�PmE�����p$AŒ�˜��ƒ�>5K /�|��H�Œ]Q9�*�V]mƒ�����<��ݻ_„V�R E{„��o�V��On!�o���U2]���+�™�6a=��(�\ˀ+W�U%�!R#ڷͷ[��Ÿ�ixƦ��H�u���� �[email protected]~k&�Az� ši �g“mBfa��3�`��“0LfհǤ#“mL�#��ƽ�#[œ�w„�%;1 SLw�œ�skq��?˜J% ���u��^�$��pe�-� ���a7GŠdŒ˜G{]H��,z™Œ'e��[email protected]"�R(���OOŸ˜hŠlŒ�� �oœfO_,B�9- S'��—:�N�<.…'����'�#����š��`Q/rP��’�i‘��š��„"��w�wiB`�lPYw�E`D�; p���A“���ҍU�nlŠŸiG����H�1���˜���)�K�� �~#�Ir�1�š ���4' šL��oa4��'�[email protected]��AA�7“`6�o��/c|��P6�–�b/Hˆ�™�tp��!P„ˆtŸ‚Ya�)x ’��•;&BŸд‘xv�/�f…–�˜� �%W;U�‹i;�ӳ˜�KŠ��1�UT�e����7‘B�Q�‡ ]i`��n�X�l�{��L�Mr��m�͡c��"_�ud‘‰™��6e�$r’M^��_GW��D�—�6J;_�›(�B��lY�o);sZ����zM�y-�R��˜�n‹u}���ߍ���Y��umW6o�7xNEx���u�Ru�n/�Z~J��ña�“ &妫�r��]� &ͧ�n�E���G]���Ĵy�W�_@ƒ��dE6�k�b���*”x—n 9F(†fi��:�-�n)k��2oM}�\A…��[S_c��”u&š7r�4r�’�[���Uʼi��a����}�xl%0��6g ^)ŠT����[~Y�tp"�H1��dbGƒš���(��0™sN�‘��˜S��›�+‡�ж�n�f9�)�{�kš�Xːr�s�z�p�S,\g'b|`a—™���—�5�-ˆg�-Kg��wv�[O^™�~>��‡��9��ˆ�������Q‰4��9l������{–†|’’N]���[w�š�$ǝ��G��V�$��—ͩ- š•�›S�{�p�eŸV+y'gSZa_�B�ѸX�E��4`�}[��Jq—��1>Yk��†��n��:lP+3vT;y���oN�h��3��sKŸ�^�+'•v�‘œ��"��o�Ԭ��G#�?r�߿�{p�s����H�Ÿ“�S|H�E�|Ի��"�{�F�Ÿ�šI��tNœ�C�#�TNV8NFyRVj�‡�3�8+�_‡���K��œI���G���lt�%†,��%/�=y�5��K‚{����Y�� �6�w8p`,u2_��wn���†Li�2û;�{�u0–�1���‘������g�>���F���wyS"��|�w�����IA�Fš†r�p.�zjc��*�>}}M����Hdw�ܧ�Ÿ��M9�X�B�9eP�����$jL“�8|&‹H��?†F/��&j���œ+3'��ƒ1����S�q”Ÿ�˜��–^�<-�4sŸ—”‰`)��lQ\��j���Ws����a�R��^Z �œ[email protected]™����†[email protected]��+œ�}™�EQ�S�„�2�ȧ1-—�8��m��rɫ4_�|e6�(, R‡��:��"�;�"‚����T��ݬG”„#'������—@˜e|Z��[�~/h��|� )��:���o�:��w����b�…‰=•dq�|:&†汸 �{�=8�—)|�]�I�m}EjFr��KQ{��6��xr����O�� `�…’>Œ4��+�z�“��\�e3r0�wMk�g“�P��x��H\�X�”9s?(:㍲��—�}̺ؐ��s}�U�C)kȼ���œ��~�D�{=�"R�—��ӭ� >���Vz�C0”~��Y,�š…�ѫ[4��?}���dҧ�Œծ@j��ͭ_"�t'�(H’`�‰•G�l��q�Ȣ"dMJ�I��Œ D�揮>–�aARc•‚�h�Բ��3����*`���/��oM���k��”[=�de:4A�Š~��Ÿ�k����:8ˆˆ�3t}›?ˬ�^�� ��*_�U�7�•�y����΢1}�x����i‹��n�Nš�A���o7�!e�+ƒAvk � ejOe<�L*���x��Aw� }ne�dP�Q���S&�fL��V�~™zNNG7��–YJ”��@t~Q�W��ä�t4T�'�Q�@ޫ,u‹�[M�y����] ��‚�P5�Y {�F<7;�9�!N)�Y��3�4�D}‡�•�:�#!���ŸC���h�“@_���—gm] …�����_^�p��+���\����c�WN]܁�'“Œ��ƒ>2#P$�‡�v��,�T?:”j��Tmx���”M��s�%t��ɬ�p"�SX"���B��f�Yix…� ‰�„^�zBWye/†{-&^`�Xn<�jKW��‹\�"�}T!�l�–~k>_1V-“��3�™{�‚����ƒrۤ }�/o��Q�„J��-sx9?�q�]�vg�•lL��[�Gy�#[��e�W��<�Eƒ\CJ�r�!_"R�1��1s����<^•�[email protected]��?ú�:A�W��|Yv� Cb�6mQŸiŠ�Vi6�“'…�•���� �5��<��0Qu��2Œ=Ͷ�T |�z�›W��–z^\����5��Š���Z��[� $�š�,–P–�5�…Œ�-`�iqj��A��.�?���=�Ym:…��M��_H‚˜?^�iƒ��zׯ�����a�~=ƒ��6���V�O�V��z�W�o›�ͱ)<�0P*z� ]�X4 4q�W�q‡n2�›���J<]o�6_�!�b�>„�m?8|(b�vu��� *�D�Х �*��:KCY\B˜�'��o��‹�A��Ao߬�1�`�F›M1��†”�0&Oѣk

Jun 01 2014
Jun 01

The community in the North… is quite hospitable and the Camp in the North was fantastic :)

:)


Drupal Camp Yorkshire 2014

Drupal Camp Yorkshire 2014

Back at Drupal Camp London Paul Driver invited me to Drupal Camp Yorkshire to deliver a session at the Camp. Drupal Camp Yorkshire 2014 was the 2nd Camp up in Leeds I am told, but from the experience I had for the short while I was there it could have been the 10th… it was  very well organised camp no doubt and next time round I will have to make sure I juggle my diary to be able to stay for the entire weekend.

Its been 6 or 7 years since I have been up to Leeds, driven past many a times but did not have an excuse to stop over, Drupal Camp is probably up there in the top 5 excuses to stop over or visit… but before I jump into the details I must mention another community who like myself had taken the Saturday off to take part in a very different but essential sort of activism.

2014-05-31 13.46.51

2014-05-31 13.46.51

On the train up to Leeds I met with a couple of ladies heading up from London, volunteers who were much like our own community giving up their Saturdays to give back.

Did’nt quite catch their names but they were activists heading up to Newark to give them folks from UKIP a hard time and to help the community there see UKIP  true ‘far right’  colours. I would like to thank folks like them who keep Britain grounded and heading in the right direction, giving geeks like me and others the ‘space’ to build, focus on and be part of other communities that rely on a certain kind of society to keep looking ahead and progressing in the right direction… probably not as eloquently put as I could.. but I am going to blame the beautiful sunny Sunday that it is right now!

Ok, back on topic, My session was on ‘Practical’ Agile product development and you can watch the video below to understand what I mean by that.

[embedded content] You can view/download the slides from Slideshare.com.

Lastly I must mention the venue, Electric Press at the Carriageworks Theatre in Leeds was by far the most picturesque of Drupal Camp venues I have have been to so far, over looking the Millenium square which given the weather was bursting with life and an open air concert set the scene up for a community event quite well.

Excellent job done by the organisers, a huge thank you to everyone who attended my session and apologies to a few friends I could not see or spend time with… for I dashed in and dashed out but will make it up to them at the next Camp or at the Con in Dam.

“Communication leads to community, that is, to understanding, intimacy and mutual valuing.”
Rollo May

Jan 13 2013
Jan 13

My last post has been a while ... in that I announced that there would be another event right before FOSDEM ... I totally forgot to announce it here but I`m sure that most of you already know. Yes. PuppetCamp Europe is coming back to it's roots... it's coming back to the city where we hosted it for the first time on this side of the ocean.. Gent. (that's 31/1 and 1/2 )

There is still time to register for the event http://puppetcampghent2013.eventbrite.com/ The schedule for the event will be published soonish (given that the selection was done on Friday evening and the speakers already received their feedback)

Co-located with PuppetCamp there will another Build and Open Source cloud day
Build a Cloud day with interesting topics such as Cloudstack, Ceph, devops and a really interesting talk on how the Spotify crowd is using Cloudstack.

So after those 2 days in Ghent, a lot of people will be warmed up for the open source event of the year FOSDEM.

And right after FOSDEM a bunch of people will gather at the Inuits office for 2 days of discussing, hacking and evangelizing around #monitoringlove (see previous post)

I almost forgot but even before the FOSDEM week-long there is the 2013 PHP Benelux Conference where I`ll be running a fresh version of the 7 Tools for your devops stack

There is a ****load of #DevopsDays events being planned this year .... the 2012 edition of New York will be taking place next week .
Austin and London have been announced and have opened up their CFP and Registration but different groups are organizing themselves to host events in Berlin, Mountain View, Tokyo, Barcelona, Paris, Amsterdam , Australia , Atlanta and many more ..

And there's even more to come .. April 6 and 7 will be the dates for the Linux Open Administration Days (Loadays 2013) in Antwerp again ... a nice small conference where people gather to discuss different interesting Linux topics .... Call For Presentations is still open ..Submit here

On the other side of the ocean there's DrupalCon Portland which once again is featuring a #devops track , and also the folks over at Agile 2013 (Nashville)
have a #devops track now. Both events are still looking for speakers ..

So if by the end of this year you still don't know what devops is all about .. you probably don't care and shouldn't be in the IT industry anyhow.

And those are only the events I`m somehow involved in for the next couple of months

Nov 30 2012
Nov 30

Listen online: 

In this episode Addison Berry is joined by four project managers to explain what project management is all about, and the impact of working with Drupal projects. Join Seth Brown, Lullabot Director of Operations (sethlbrown), Jerad Bitner, Lullabot Sr. Technical Project Manager (sirkitree), Matthew Saunders, COO of 5 Rings Web and a Principal of Vintage Digital (MatthewS), and Drew Harteveld, VP of Digital Operations at Martha Stewart Living Omnimedia, as they give some insight into their crystal ball secrets.

Project Management

If you want to suggest ideas for podcasts, or have questions for us to answer on a podcast, let us know:
Twitter
Facebook
Contact us page

Release Date: November 30, 2012 - 10:00am

Album:

Length: 60:55 minutes (34.86 MB)

Format: stereo 44kHz 80Kbps (cbr)

Nov 30 2012
Nov 30

Listen online: 

In this episode Addison Berry is joined by four project managers to explain what project management is all about, and the impact of working with Drupal projects. Join Seth Brown, Lullabot Director of Operations (sethlbrown), Jerad Bitner, Lullabot Sr. Technical Project Manager (sirkitree), Matthew Saunders, COO of 5 Rings Web and a Principal of Vintage Digital (MatthewS), and Drew Harteveld, VP of Digital Operations at Martha Stewart Living Omnimedia, as they give some insight into their crystal ball secrets.

Project Management

If you want to suggest ideas for podcasts, or have questions for us to answer on a podcast, let us know:
Twitter
Facebook
Contact us page

Release Date: November 30, 2012 - 10:00am

Album:

Length: 60:55 minutes (36.81 MB)

Format: mono 44kHz 84Kbps (vbr)

May 11 2012
May 11

Drupalcon MunichHere we go again! Drupalcon Munich is just around the corner - August 20 - 24th. That may seem like a long time, but for a veteran of organizing one of these events, I can tell you that the work is ramping up rapidly. All my best to our friends and colleagues over the pond who are, undoubtably, working like crazy. I'm looking forward to enjoying the next convention not being behind the scenes.

Over the last few months I've presented on Agile Scrum twice. Once, as one of the Drupalcamp Austin Keynotes and a second time at Drupalcon Denver with my good friend Stacey Harrison. The presentation evolved from one of the events to the next. I've continued to wear my presenter hat and am ready to do Mark III on the topic of Hybrid Agile Project Management.

Learn from the experiences of Examiner.com's team. We've done it all - cowboy, waterfall, extreme, and agile scrum.

Learn why...

  • Waterfall doesn't always work
  • Agile has a place, but isn't the holy grail
  • Cowboy can kill the relationships you have with your stakeholders
  • How "Fixed Scope" is a lie
  • That a combination of approaches is the answer
  • The Examiner team has carefully honed, updated, improved, and iterated its process for over two years. It continues to evolve, improve, and make development more consistent and predictable.

Project management requires a blend of techniques and tools to effectively shepherd projects from ideation to release. We'll explore and discuss different tools and methodologies that can help make your project successful.

I'd love the opportunity to continue to share my learnings over the last 16 years with a particular focus on the immediate previous 9-12 months. Examiner's process has changed, evolved, improved, and continues to become increasingly awesome. If you're interested in seeing me present, please pop onto my proposal and leave a supporting comment!

Over the last few years I have become great friends with Rick Nashleanas of Monarch Digital. On the last day of Drupalcon Denver, he and I spent quite a few hours chatting, eating, and drinking and ended up cooking up a plan to present together. We're hoping this first faure together might occur in Munich. Come chat with us about recruiting and retention, about active listening and communicating, and about being mentored and mentoring.

Drupal has been around for about a decade. Information Technology predates it about about 5000 years - the Premechanical, the Mechanical, and the Electromechanical segued into The Electronic Age in the 1940s. In the 1950s what we would recognize a Project Management began evolving. There have been Project Management truisms across time.

Sit with two veteran IT managers and leaders (who also predate Drupal) to discuss:

  • Recruiting - Where and HOW do you find people?
  • Retention - How do you keep and nurture those you have?
  • Zen and the art of listening... and hearing. How to hear your clients, your peers, your subordinates, and those you report to.
  • Mentorship - Designers, Coders, Project Managers - How to grow within and beyond your discipline.

Attendees should bring questions and ideas that can be explored by the entire group.

If you'd like to see Rick and me engage in entertaining, informational, and engaging buffoonery - please write a supportive comment on our proposal. Here's to our next community event! Sharing, contributing, and participating brings me joy. I hope I get the chance in Munich.

Dec 28 2011
Dec 28

The next few days are like a timer counting down. Sometimes the conversations feel a bit like a NASA control room. We review and re-review our plans because this deployment isn't going to be a small one. It is likely in the top 3 in scope since I began over two years ago.

Day 12 - Testing

We started with Scrum, Scrum, Scrum, and Scrum of Scrums.

Testing continued on Day 12 - and all the while we continued to work through Product Manager user stories. Supporting artifacts were shared as well. This segued into the Project Managers reviewing points and starting to assign teams for the next timebox. For this cycle, we found that our story points were roughly double to the number of the points available for the next timebox. This requires a feedback loop with the Executive committee to prioritize completed set of user stories.

The Executive Technical Leadership Committee met where we discussed a variety of issues, successes, and follow ups from the prior week. This committee fulfills the role of a CTO.

Finally, I also reviewed a patent application.

Day 13 - Testing, Stories, and Horse Trading

We continued to work through user stories and test. We had a 90 minute meeting with the Executive Committee to discuss the priorities where some items were shifted lower on the priority list and, for intents, got knocked out of the upcoming timebox and into the next.

Testing is coming to an end at this point. Day 14 will be release day and so only the most critical items are prioritised to be addressed before we release. This means several status meetings throughout the day. In this timebox, we were still engaged with status meetings until later in the evening. This was partially due to a timebox that was 25% smaller than our normal 20 day period. It was also in part because we launched our new mobile experience transitioning from a third party, Verve, to an entirely Drupal based mobile site. This shift greatly enhances the user's experience on a mobile device by leveraging block logic from the desktop site and providing access to all Examiner.com content. The Verve experience was limited to the previous 30 days.

User stories and the supporting artifacts are being heavily examined at this point. We have to lock down our next timebox on Day 14 - and that is now less that a day away. We also anticipated that the morning release would be long based on the new features that have been made ready during the current timebox and previous ones. The good news is that the work of creating stories is largely done - there are a few holes that need to be filled - but there is also bad news. Even with the prioritization of scope, the points that will be needed for Timebox 6 exceed the points we have to expend. This will mean and tertiary review prioritisation prior to the planning days 1 and 2 for timebox 6. Fortunately the holidays have afforded us a week in which the team will be largely working on defects giving enough breathing room before the next timebox starting to do that evaluation.

Work went late into the evening. There was a 6 am MT release start time.

Day 14 - Deployment Day

We start at 6 am MT - a time which is a compromise between low traffic and a time when our entire distributed team can be available. Most of us work on deployment from our homes rather than in the office. We have several communication lines available during our deployments.

  • A logged "Live" IRC channel
  • A logged "Post Deployment Validation" IRC channel
  • This timebox we added a Voice line using Skype

We want everything logged during deployment. If we need to go back and see what someone was doing at any given time, the logged channels help in those forensics. Anything that is spoken in Skype is to be logged as well. The goal here is to allow for extremely rapid communication in an emergency that doesn't rely on the typing speed of any one person. One of the lessons learned in a previous timebox was just that - fingers, in a pinch, cannot trump the speed of someone saying out loud, "STOP".

Normally deployments, from start of code push to end of post deployment validation, take 2-3 hours. We were launching a new mobile site making this deployment a longer process. It was about 10 hours total if you include hot fixes that occurred after validation to mitigate defects that manifested after push. After the code push is complete and post deployment validation is done, team leaders huddle and discuss which issues that have arisen need to be addressed immediately. A rapid triage occurs were we identify what order the needed changes will be pushed. They are then fixed, pushed to staging, validated, pushed to production, and validated one at a time.

After deployment is complete, it is time to do the final lockdown of stories for the next timebox. Folks have one last opportunity to lobby for switching priorities. Stacey is busy preparing our demo plan for the next day and informing folks who will be presenting what order and for how long.

Day 15 - Demo and Retrospective

Demo Day - when we arrive we will start to prepare the Examiner lounge - it has a large screen that we hook laptops up to, a video camera so our virtual team can peek in and take part. We set up a Skype call and a video feed for folks to access. The demo lasts for about an hour with each Product Manager going over the work we've completed during the timebox. Generally several of the Development Team will present something as well. This time around quite a bit of time was spent on the new mobile experience and America Inspired which will, on the 9th of January, will boast a brand new flexible polling module with different states for roles and voting status.

The retrospective was held as a round table. It is designed to be a safe place where we can honestly discuss what worked and what didn't work in the timebox. It allows us to make adjustments to our process. We have changed things like timing for artifacts, length of our testing period, adding a environment synch and freeze between prod and staging for a few days after deployment, and adding voice to our deployments.

Rinse and Repeat

The process repeats itself. Currently we are moving into development for our 6th timebox, user stories and artifacts for timebox 7, and ideation for timeboxes 8 through infinity. We track our burn rates pretty closely and are able do a good job of estimating the time our stories will take. Every timebox we complete improves our team's efficiency. We learn new things about how to do our jobs better every 20 days. I am incredibly proud of our team and how our process has grown.

Image Credit from Flicker. "Stopwatch" by William Warby
sed under a Creative Commons License.

Bookmark/Search this post with:

Dec 20 2011
Dec 20

We Were Busy
Today was an extraordinarily busy day in the timebox. We're in the midst of attending to revealing defects in our current release, some fairly significant configuration work to support America Inspired, reviewing tons of user stories, writing user stories, and continued work on setting up JIRA with Greenhopper to replace our ticketing system.

The Scrums
The day started out, as usual, with three scrums that cover the work our three distinct teams are working through. The scrums at this point are less about the developers telling us what they've worked on, what they are working on, and what blockers they have and more about the QA team reporting on results that have come through testing. We do look at our story board spreadsheet to confirm that stories are either green or nearly green. We also make hard decisions on features that might not be ready for release in the time box. Those are noted and we socialise that news with stakeholders as appropriate. We're also looking at any stories that might be at risk and identify alternate plans for those stories. That might comprise a) deferring the story for completion in the next timebox or b) completing the work during the QA week or c) releasing the new feature partially. Finally, the project management team got together for a scrum of scrums where we identify any problem areas that might have emerged.

Stories, Stories, and More Stories
This day quickly moved into several hours of team leads reviewing user stories with a great deal of detail. On or around the Backlog Mambo, the project team is giving a rough pointed estimate to the stories as they are completed. This is to have a general sense of the needed burn rate to compete the next timebox's work. It gives the Executive team a little more information to be able to prioritise the work. During the QA week, the development team is challenging these assumptions and either confirming or disputing the time frames. We're generally pretty good about our estimates. It is common for priorities to shuffle a bit during this period of time as well. Scope on one of our initiatives increased while we read through the stories and realised there were a fair number of cases that hadn't be identified and drawn up. There was, also, new functionality being discussed. All of this is fine as long as we have our stories nailed down along with the accompanying artifacts by the time we lock the timebox down. This sprint, it will happen on day 15 although during our normal sprint it occurs on day 19. We reviewed about half of the current user stories and pointed all of them. Looking at the needed burn rate, the list needs to go back to our Executive team for prioritization. User story review will continue on Tuesday and Wednesday.

Ideation, Performance, and Configuration! OH MY!
The day also had us looking at solutions to improve overall performance on the site. These conversations have ranged from reducing the amount of third party Java Script on the site to more agressive caching to creating a Boost-like flat HTML methodology. Stacey and I started the next timebox's planning for who will do what - the general breakdown of what our teams will look like this time round. One each, of our product managers, designers, QA member, developers, and I started new configurations in our staging environment to script out a process on the live site for support of the America Inspired initiative. There are many blocks to be configured, placed, and visibility settings to be tweaked. Articles will need to be grouped into the five areas and labeled correctly. In short, we're drawing up a plan for the next two phases of that program.

The Tickets
Finally, we are engaged in defining how our instance of JIRA will behave once we have finishing configuring it. This is requiring our reviewing each and every kind of task we engage in and defining workflows for each. It is a significant effort.

That rounds out Day 11 of our Agile timebox on this very large Drupal site.

Photo Credit on "User Story Template": jbeau on Flickr

Bookmark/Search this post with:

Dec 17 2011
Dec 17

The last few days have pretty much been nose down to the grindstone coding like crazy for the development team. Days 5-9 were pretty much the same with a few exceptions.

Day 7
On this day the Epics and High Level User Stories were delivered and these helped define user stories that needed design artifacts. The project team started sifting through the stories to identify any pitfalls or problems. As the Technical Product Architect, I start to think really hard about approaches that we might be able take when we get down to the Drupal part of the implementation. Are there any contributed modules that might fit the bill? Sitting down with various Product Managers we began detailing how the product vision would technically be handled.

Day 9
Largely the user stories were delivered. As a team we really started doing a great job of reviewing individual stories. Certain members of the development team had their features code complete which opened them up to help review the stories that were being delivered. We started looking at wireframes.

During these two days, the Executive Committee were helping continue form priorities for the next Timebox.

Day 10
Today was a transition day. If you look at the first post in this series, you'll see that the days turned from blue to yellow today. This represents a handoff of the environment to the QA department to start reviewing code that has been completed and pushed to the staging environment. This transition is also the first day that the development team throws themselves largely into helping review stories and wireframes. It is early enough in testing that there are few defects being sent back for rework.

First draft comps for the next timebox are also due. In our case, wou can watch the box.net directory synch as comp after comp are dropped making them available for the team to review. I've noticed that the transition day tends to be heavy on meetings. A sampling for example, today, had:

  • Three Scrums
  • One Scrum of Scrums
  • Part 1 of a Config Dry Run for a new set of features
  • Ideation for a new project that will lead to User Stories
  • A ticket system transition meeting
  • A reports meeting

The next three timebox days will finalise our user stories for the next time box with both the development and product groups. We will continue testing and reworks.

Bookmark/Search this post with:

Dec 09 2011
Dec 09

Day 4 of a Drupal Timebox
Yesterday was the first day that the Examiner.com development team was really coding. That became conversations in IRC and the beginning of features being sent to code and theme reviewers. The spreadsheet that we keep our user stories in is starting to move yellow stories to green and the salmon stories are being turned yellow (white is uncommitted stories, grey is deferred, yellow are committed to being developed, salmon need more information, and green are ready for manual QA). This is the time when the developers really get their heads down and are working hard to complete the stories they have allotted in the time period available and work on the bug backlog.

The morning began with our regular scrums - three teams, three scrums, three sets of projects. This post doesn't need to rehash our morning scrums.

The day was peppered with meetings including a review of current Infrastructure needs and ideation of new Ad targeting techniques with a Product manager. It included working through planning a business trip to work with another company on an Examiner project. We're also still working through retrospective improvements from the previous timebox.

The Backlog Mambo
We embrace the idea that the current work we're developing should be predictable. The current timebox development should be pretty much set in stone. There are times with opportunities or threats are so great that we need to suffer the challenges of context switching. This should be rare. Anything after current development should be negotiable. That is what a large chunk of today was all about.

Yesterday, the Product team brought to the Project Managers a prioritized backlog for the next timebox. This list was a first pass based on Executive Committee directives. The Executive Committee convened today with the Product Team, and representatives from Business Intelligence and Development. The top items in the list were discussed and adjusted. Scope was shifted and priorities were moved. There were requests to fatten out some additional initiatives. The next two weeks will have the Product team focused on developing user stories in conjunction with development and Creative working with themers on wireframes and comps.

The dance continues.

Bookmark/Search this post with:

Dec 08 2011
Dec 08

In the first two posts in this series I wrote about the planning days at Examiner.com and how those planning days set up the beginning of the code sprint. I also discussing the ancillary activities that set us up for the next timebox - locking down the priorities for the next time box.

Today, Day 3, the coding portion of the sprint begins.

The scrums started out by reviewing the salmon stories (salmon are stories that still need more information to be actionable) in the Google spreadsheet. Each story, as clarified was turned yellow - indicating the team in committing to completing the effort to complete that work. After these stories have been reviewed and clarified, the different groups are tasked with different tasks.

The morning began with three scrums. Each scrum represents a practicing unit that includes:

  • A Project Manager
  • A QA Person
  • A Product Manager
  • Developer(s)
  • Themer(s)
  • Code Reviewer
  • Theme Reviewer
  • Release Manager

There is some overlap between the scrum teams - but we try and keep the units as separated as possible.

Developers and Themers
coding coding coding

QA Folks
The QA team works on building test cases to support the next period of the timebox. They take part in meetings, as needed, in the development of use cases and review of artifacts for the next timebox.

Reviewers
The reviewers start to be fed features to engage in code review on. If code passes - it moves to the next development step. This could be theming or it could be Manual QA. If it is ready for QA it is pushed to staging for functional testing.

Release Manager
pushing pushing pushing

Product Managers
Product managers are responsible for delivering the prioritized list for the next timebox today (Day 3) and begin to work through writing user stories for the next timebox. They are also responsible for answering questions about user stories in the current timebox. Any discovery for two timeboxes out and beyond is happening as well.

Project Managers
Project Managers act as defense during this period of time. They are responsible for clearing blockers and preventing the development team from being distracted by tasks outside of directly programming new features, enhancements, and attacking the defect backlog. During this time the Project Managers are also working with the Product Team to develop user stories for the next timebox. The Project Managers are also socializing updates, considering requests, and trouble shooting problems during this period in the spirit of keeping the development team from being distracted.

What Else?
The day also included reviewing processes that were identified as needing adjustment during the previous retrospective. I, personally, worked on setting up meetings with various parties to support future development tasks including a potential upgrade to Open Atrium. We use Open Atrium as our Intranet for Examiners (our writers). We reviewed our defect backlog to start scheduling the highest priority bugs into the current timebox. People in the company make use of this time to discuss potential approaches for new features. Discussions with the Project Management team direct new features towards contributed modules as much as possible. Plans may start for code reviews on contributed modules that might be used in the next time box.

The take away is this - the developers, themers, testers, and reviewers are all focused on what we are developing now. The focus of the product team is starting to move strongly to the next time box. Project management is straddling these two different sets of activities while herding the collective cats.

Bookmark/Search this post with:

Dec 07 2011
Dec 07

Day 2 - More Planning

Day 2 of this shortened timebox was the second of our Technical Planning days. As I mentioned in my previous post, we have two half days of Technical Architecture/Planning at the beginning of the time box. We continued to review details on the user stories for this box and also tightened our estimates a little bit for remaining stories. We look at whether we need to write code from scratch, we can make use of community code, or enhance community code from the Drupal project.

We colour code our stories - white for not scheduled, yellow for scheduled and committed to, greeen for QA ready, salmon when we need more information, and grey for stories that we defer for future timeboxes. We re-reviewed stories from yesterday for which we needed clarifications. These visual queues make it really easy to scan the Google spreadsheet(s) and see the status of a given story.

Our story spreadsheet header describes the information we're looking to capture for hand off to the development team.

We capture a story ID - and will do point increments when we have sub-stories related to a given feature. Each story must be associated with a ticket and includes the description of the story, questions from various team members, and points to illustrate the level of effort. One point is a half day in our world.

After The Technical Planning

The three project managers then finished breaking up the projects between them. We try to all take part in the planning days so we're in the loop on all the projects. Projects are typically broken up into development groups with an attempt to have as distinct a team as possible with little overlap. This is sometimes difficult as all code is reviewed by another developer and another themer before it even has a chance of making it out for QA.

We also ended up having our retrospective from the previous timebox today. Typically that would be scheduled for day 20 in the timebox, but constraints delayed this meeting. We tweaked our process in a few places. For example, much of our discussion is done in IRC - we decided that for our releases we would add voice to the mix for the end of this timebox. We use logged IRC to keep our decisions and conversations logged, but sometimes you need a more rapid way of getting another person's attention.

We're Starting the Next Timebox?

Finally, Day 3 of the timebox is the point when priorities for the next timebox are shared by the Executive Committee. Today was a day where a representative from the product team, from the project management team, and from the release team met to put final "t-shirt" LOEs on the prioritized feature backlog. The list of desired priorities will be delivered tomorrow and user stories, wireframes, and comps for the next timebox will begin to be generated. In a very real way Day 2 represents the first day of the next timebox.

What's Next?

Tomorrow will be the first day of our code sprint which will last for 7 work days. The team will also start on user stories based on the priorities set by the executive committee.

Bookmark/Search this post with:

Mar 13 2011
Mar 13

At DrupalCon Chicago this past week, there was a "Core Conversations" session track, made up of sessions pitched by contributors to the core Drupal project. A wide range of topics were covered from the Butler project (a new system for context and blocks), to the built-in Help system, to Deployment strategies, to redesigning the issue queue. These sessions were shorter presentations followed by a discussion period for the attendees to give input on the topics.

The final conversation on Thursday by Dries Buytaert (Drupal's project lead) focused on discussing the development process for Drupal 8. (It was also exciting to witness the Drupal 8 branch being created live during the session!) During the presentation portion, Dries described in more detail the process changes he had suggested during his keynote. He then opened the floor up for everyone to bring up issues they felt needed some attention/discussion.

Discussion points

Here is the list of discussion points (that Dries noted during the talk) we core enthusiasts came up with:

  • More structured sprints - project management
  • Sandboxes (aka. Samboxes, since Sam Boyer was a huge contributor to Drupal's CVS to git migration) and locations
  • Timeline of release cycle
  • Hybrid development cycle
  • Ubuntu model?
  • Gate details; performance testing, etc.
  • Roles of initiative owners
  • Backporting
  • Non-initiatives / small changes / bugfixes -- different process?
  • Tools for usability/accessibility
  • Process around new initiatives / proposal
  • Documentation gate - workflows

Many, but not all points were discussed, and as we progressed through the conversation, I began to see parallels between some of the process changes we've implemented here at Affinity Bridge and what's going on in the Drupal development process. When I first began my position as Project Manager here, the first task I was assigned was to figure out how to make our development process work better, especially for larger, ongoing projects. This was sparked by the pain of working on very large projects, with huge issue backlogs and many feature requests, and no set launch date. 

After a lot of reading and research, our team started experimenting with a more agile process. Picking smaller chunks of work, completely finishing them, picking a new chunk of work, completely finishing it, etc. helps to make progress faster and at a better quality. Many times now, the benefits of this process have proven themselves, and I am beginning to see how some of the main points we discussed at the core conversation could be addressed with some incremental changes towards a more agile development process. 

A sidenote, as I was discussing this over the weekend, Bruno De Bondt from DeWereldMorgen.be pointed me at a blog post from one of his old coworkers from Krimson (a development shop in Belgium), Kristof De Jaeger (aka. swentel). The post is from about a month and a half ago, and outlines a proposal for an agile Drupal 8 development process. He goes into much more detail about the process and different roles involved than I will here, but it is well aligned with my thoughts (and potential long term vision), so I recommend you read it!

Specific ideas about sprints and agile for core

Before I delve into details here, I would like to preface this by saying I am not a religiously devoted agile follower. So far, what I've seen work is using elements of the agile methodology that fit for the team and project. Some devoted capital-A "Agile" followers might find that to be a flaw, but I don't think it's necessary to shoehorn people into a process. It's important that anyone adopting this feel comfortable with it, and not forced into it. Also, speaking briefly with Dries after the core conversation, he noted that it's important with such a large community not to try and undertake too much change at once (referring to the git migration and also the new idea of core "initiatives"). I very much believe those are wise words, and so am more keen to suggest some practices that the community can experiment with. If these are successful, then perhaps they can be applied more overarchingly.

Now, to go through a few of the main discussion points and others that came up, and relate them to how a more sprint-based/agile process might help address them.

New opportunites from sandboxes and git

The move to git is obviously going to open up many doors as far as more collaborative work and changes to workflows. Any Drupal.org user can now have their own development sandbox, and as Dries mentioned anyone can now fork core (ie. make a duplicate version and add improvements to it), though it's not always recommended! 

As many others noted in the session, this is going to allow multiple people to easily work on different parts of core and then merge their work back together. It could also allow multiple people working on different approaches to the same parts of core, to then compare and combine the best pieces. In any case, it will allow for a lot more safe experimentation and collaboration.

Keeping the criticals count below 15

This was something Dries brought up in both his keynote and the session. The Drupal 7 release cycle was very drawn-out because of the large quantity of criticals accrued through the three years of work. Longer release cycles tend to lead to burn-out and work that doesn't get fully completed.

Having the sandboxes and git will allow for a totally new approach here, one which is common to a more "agile" process, which prioritizes keeping the master branch clean and ready to launch at any time. To work like this, the master branch for core would be kept in a launchable state, and any changes or new work would be done in branches/sandboxes which would have to be completely done to be merged back into core. The "gates" would protect the master branch from bugs or incomplete work, so that we could be relatively certain that core is always ready to ship.

As a result, we wouldn't be aiming for under 15 criticals, but rather a constant of zero criticals in the master branch.

Small changes and bug fixes

Small changes and bug fixes would also be done in branches, but merged back in more frequently. There would be no necessity to save up batches of small fixes, though they could be done in batches related to different pieces of functionality. 

We would want to aim to avoid incurring technical debt, ie. fix problems as we go, as much as possible. Never delay working on bugs that will need to be fixed before launch. If that's the case, the work is not "done" and should not go into the master branch. This may mean more refactoring, but it helps keep the master branch ready to ship at all times.

Gates

The "gates" Dries talked about are still being defined, but the general idea is that there would be some steps that need to be completed before any branch would be merged into the master. Examples of what gates there might be include:

  • Documentation: making sure all of the code/API documentation is complete/updated, and ideally make sure the online documentation is also complete/updated. Possibly could go through review by Documentation Team members or other developers.
  • Accessibility: making sure that basic accessibility standards are met. Possibly could go through review by Accessibility Team.
  • Testing: making sure automated tests are written and pass. Possibly could go through manual testing as well.
  • Performance: making sure performance meets certain standards.
  • Design/UI: having design or usability reviews.

Making this concept of "gates" work will require defining a set of requirements and standards, and possibly finding people willing to do frequent reviews. But it will also mean that this additional work is really done before merging into the master branch, and that "done" refers not only to code being complete, but a more holistic interpretation of when work is ready to ship.

Timeline of release cycle

Dries suggested a shorter release cycle for Drupal 8, with likely a more focused and smaller set of initiatives (which he's outlined as areas of focus that will have initiative leaders). Keeping the master branch ready to ship at all times will mean that the release cycle can be as short or long as we want, and that we are not limited by half-finished functionality in the master branch (since only finished functionality would ever be merged in).

More structured sprints and phases

A lot of these goals and ideas lend extremely well to working within more structured sprints, and using phased development for larger initiatives. My initial suggestion (Kristof's post suggests two month sprints) would be for one month sprints. Despite the issue of working with a spread out team of mostly volunteers, I find that shorter sprints lead to better momentum. I also feel that it will be easier to pick out clear sets of issues to work on per sprint if they are relatively short.

Another benefit to shorter sprints would be the potential to attract more help from people who aren't interested/able to work on core more consistently. It's a lot easier for someone to commit to working on some functionality for a month rather than for three years. I would bet that once someone helped with one sprint, they would be far more likely to end up helping on another one down the road.

For larger pieces of work, we'd want to work in phases that are several sprints long. Each phase would have a set of functionality that can be merged with the master branch when complete. And the end of each phase would be a great place to work through the "gates". It would be nice to think we could go through the gates at the end of each sprint, but I don't think we currently have the resources to do this. It might take many phases to get an initiative fully complete, but the length of the initiative wouldn't necessarily delay a potential release.

A note on infrastructure...

Structured sprints would be much easier to do if we were able to add "sprint" and/or "phase" fields to the issues, but even without this we can always organize what is in each using tags, as was done with the git migration.

It would also be ideal to be able to relate issues in a richer way like in some issue tracking systems such as Unfuddle (see image below). Despite Unfuddle not being created specifically for agile development, it's easy to use it this way. I tend to create "parent" tickets for meta-issue/discussions and then create specific work item tickets as "children". You can also mark "related" issues, which aren't part of the batch of tickets, but are somehow related. And you can have parent tickets that have child tickets that are parents to others, so it's possible to create a hierarchy of what needs to be done to move onto another piece of work. Then, I create a "Milestone" for each sprint, with start and end dates, and add and prioritize tickets in the milestone appropriately after discussing priorities with the product owner and the development team.

If this interests you, there are issues filed for redesigning the issue queue and creating functionality to support meta-issues that you can add your opinions to.

Project management

This all seems to beg the question: does the Drupal project need a dedicated project manager (or scrum master)? 

At this point, I would say no. Between Dries (who tends to fill the product owner role), the core maintainer he appoints (who tends to act somewhat as a project manager, and does a lot of QA), and now the new Initiative leads, I don't feel that this would be necessary during a period of more experimental adoption.

If teams and individuals try this method, and find it works well enough that it could be adopted fully for all core development, it would be a very good idea. A much more structured process takes a lot of work to keep organized and stick with, and I believe it's best to keep developers' time free to be dedicated to development as much as possible. So at this point we would want to create some overall structure in the issue queues to be able to manage sprints efficiently, and have someone who can oversee the project's organization as a whole.

Realistically, I don't think this would be necessary very soon. For now, I would suggest anyone interested start with:

  • Running set sprints (recommending one month). Meeting at least once per sprint (on IRC or by voice) to review and align priorities amongst whoever is working on a given issue/set of issues/initiative. Communicating frequently on IRC (like we always do!).
  • Defining work to be done at the start of the sprint, and doing your best not to introduce new work into the in-progress sprint. In the beginning, underestimate how much can be done, until you get a feel for the momentum possible in a single sprint. If some things don't get finished, they go back into the "backlog" (or main queue of issues) and are reevaluated in regards to whether they will be in the subsequent sprint.
  • Making sure at the end of the sprint (or phase for larger initiatives), that you pass through the "gates" and deliver functionality that is completely "done" and ready to merge into the master branch.
  • Making sure that no bugs get into the master branch so it can always be ready to ship. As a result being able to make the release cycle any length, and launch on short notice if desired.
  • Avoiding technical debt (things that you put off that will need to be done later); making time for refactoring or bug-fixing as you go. Possibly even having a technical debt recovery sprint early on.
  • Defining the "gates" clearly and deciding who is responsible for signoff before merging into the master branch of core.
  • During this experimental phase, making sure there are some resources that teams and individuals can refer to and learn more about these methods. Possibly looking for project managers in the Drupal community who are familiar with agile development, and open to informal advising on IRC.
  • Remembering that this is a pilot project of sorts. Not putting too much pressure to follow capital-A Agile strictly. Letting this be an organic process to see what fits the community best, while leading to a more efficient, clean, and smooth process.

I was extremely happy to hear how open and interested the other attendees of Dries' core conversation were, and hope this helps clarify some ideas. This should be an open discussion rather than anything too prescriptive, so I would love to continue the conversation and hear your feedback, questions, and concerns below.

(ps. The Drupal 8 wordmark used with this post on the homepage is from Dries' slides, just for the record!)

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web