#agile software development

[cprime-project-management-blog]

The Agile Development Story: Scrum Meets PMP

by Crystal Lee, PMP, CSM

Do you know what a Scrum is? Wondering if you should try Scrum on your next project?

If so, you’re not alone. It seems like everyone in the software development community is buzzing about Scrum. In this article, we will present basic principles and remove some of the mystery around Scrum, compare Scrum with current Project Management practices, and go over some tips if you are thinking of using Scrum for the first time.

Despite the recent buzz, Scrum is not a new discipline. Like Rational Unified Process (RUP), Scrum came out of the object-oriented programming movement in the 1980’s. Today, Scrum is one of the more well-known Agile software development frameworks in use today.

In the Scrum literature, we will find many familiar companies that are cited as examples of successful Scrum implementers including Google, Yahoo!, Accenture, Nokia, Sabre, Lockheed Martin, Salesforce.com, and the BBC. Some companies have taken the extreme step of making Scrum the prevalent mode of planning and delivery throughout the organization, from marketing to facilities management.

What Is Scrum?

The term comes from rugby, where a “scrum” is used to restart the game after an event that causes play to stop. Each opposing team forms into a human wall three players deep, pushing against the other team to kick the ball out to their side. It’s the ultimate in teamwork and strength. Taking the analogy to software development, Scrum is based on multiple small teams working in an intensive and interdependent manner to deliver a piece of software.

The Scrum process flow is structured in cycles of work called Sprints. A Sprint is usually two to four weeks long, and is similar to an iteration in Rational Unified Process (RUP). At the start of each Sprint, teams pick features from a prioritized list of customer requirements, called user stories, so that the features that are developed first are the most important according to the customer. At the end of each sprint, a working “potentially shippable” product is delivered.

The full Scrum team has 7 members (+/- 2), including the Product Owner, the ScrumMaster, and the Scrum core development team. As the projects increase in size, the number of Scrum teams also increases. The fundamental components of Scrum are Roles, Ceremonies, and Artifacts. For the purposes of this article, we'll forego further details about these Scrum concepts.

Scrum and Classic Project Management

Is Scrum compatible with classic project management as defined by the PMBOK® (Project Management Body of Knowledge by the Project Management Institute)?

The answer is yes, because Scrum is a process framework and is not really comparable to the PMBOK®, which seeks to standardize project management best practices. Scrum is not only compatible with the PMBOK®, it can be complementary.

Being a ScrumMaster is also not unlike being a project manager, and the two roles can even be shared by one person. Like any good project manager, a ScrumMaster facilitates, coaches, mentors, removes obstacles, communicates, and protects the team.

It may even be that as a project manager, you are unknowingly practicing Scrum techniques. Symptoms of Scrum-like behavior include:

Surrounding yourself with a highly-specialized and high-producing team who share commitment and trust;

Assessing progress on a frequent basis (optimally daily);

Reviewing requirements frequently, and reprioritizing if necessary (optimally monthly);

Identifying doable short-term goals with your team and showing accomplishment frequently (every 2-4 weeks);

Allowing experienced team members to assign tasks to themselves because they know what is needed to get the job done;

Bubbling up the right amount of information to stakeholders through visible and effective communication.

However, each organization adopts Scrum differently, and so the implementations of Scrum can vary greatly. Some “Scrummified” organizations have PMOs, some do not. As you learn about Scrum and experiment with it, you will begin to see how the entire organization might have to go through a mindset change to use Scrum fully and correctly. PMOs might have to examine their charter and make modifications to work with less rigid Scrum processes. In some organizations, it could be analogous to the change that had to happen when the move to project-based work was first made.

How to Start Scrumming

By now you are probably getting the idea that Scrum is definitely not a slam-dunk. Most companies tend to test Scrum with a trial project and leave the rest of the company using existing methods until the results are proven.

Here are some suggested steps to follow if you are thinking of implementing Scrum for the first time.

Find an executive sponsor in your organization who will support you and your Scrum endeavors (this point cannot be overemphasized).

Analyze how and if Scrum fits into your current environment.

Find a test project that does not have a major business impact but is still important to the organization.

Find a team of like-minded people who want to make Scrum work.

Provide training for the ScrumMaster, Product Owner, and Team Members. All of the team members could attend one course together so that they understand everyone’s role.

Hire an experienced ScrumMaster who will drive the project and mentor the team, especially the new ScrumMaster.

Getting Certified in Scrum

If you are interested in gaining more expertise in Scrum, the first step is to take a Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO) course. Unlike other certifications, the CSM or CSPO does not qualify you as an expert. It does mean that you have been trained in what a CSM or CSPO is supposed to do. The next step in Scrum certification is Certified Scrum Practitioner (CSP), which requires applicants to be an active CSM or CSPO and show one year of hands-on Scrum experience. All Scrum Certifications are for two years.

You will find more information about Scrum on these websites:

http://www.scrumalliance.org/ - Scrum Alliance. Scrum Certification body.

http://www.agilealliance.org/ - Agile Alliance. Has information on Scrum.

http://www.apln.org/ - Agile Project Leadership Network. Has information on Scrum.

The Future of Scrum

It is not yet possible to predict where the Scrum movement is going to end up. Is Scrum going to become just another entry in the already crowded field of Agile frameworks, like Lean Development and Extreme Programming (XP)? Or is it going to gain more momentum as larger organizations move towards a more “Scrummified” model? Of course, Scrum is not the only way to run projects, but it is certainly a burgeoning movement that has gained more publicity than most other Software Development methodologies.

Certainly Scrum has not worked for everybody. There have been classic failures of Scrum, but there have also been failures with waterfall, RUP, XP, and any of the other development methodologies around today. Probably the best advice is to be flexible when considering which framework to use. Just like you don’t wear the same clothes to work as you would to a football game or to a wedding, every technology project will be different and different frameworks and processes can be applied depending on the need for speed, reliability, profitability, or usability.

In fact, research is showing that the success of a methodology may lie more in the execution than the underlying principles. The more maturity and experience team members have, the less rigid the direction may need to be. So just like in rugby, if you are going to Scrum, make sure you Scrum with your eyes open and a good team around you.

Have a comment about the article you just read? Interested in getting more information on how to implement Scrum on your project? Send an email to crystal.lee@cprime.com. We welcome your questions, comments and feedback.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More...

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI's Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

[shaunbebbington]

Reasons for and against test driven development

Reasons to use test driven development:

It helps you break down problems into manageable segments before a line of code has been written.

If you can write a test for it, have some idea of the results that you're expecting.

If you have some idea of the results that you're expecting, you understand the specification of the software that you're writing.

Once you're satisfied that a test has been passed, you can move onto the next problem, i.e., writing the next test case.

Reasons not to use test driven development:

You don't understand, or are unfamiliar with, the specification that you've been given.

Not enough thought has been put into the specification, therefore it is likely to change.

You think more lines of source code means that you're more productive.

Test cases is like comment blocks: nobody needs them.

You like to spend lots of time debugging.

[velocitypartnersblog-blog]

 Again expert Bob Galen, Principle Agile Coach and consultant, recently posted a blog on our website that is extremely helpful to the community. He discusses a pattern of collaborative partnering over embedded UX in the teams or independent UX outside of the teams.   Bob illustrates the point with a story that involved helping a client to understand and practice release-level planning across Scrum teams.  He discusses some of the changes that were a result of his advice such as incorporating UX design work and cross-team dependencies in their projects. 

In his example, the firm had hired a talented designer who was given the job of redesigning a few of their legacy applications as well as designing some new components. The problem was that the designer reported directly to the Chief Product Owner and developed an entire view toward a redesign of a specific area in their product line.  Furthermore, it was done without any input from the development Scrum teams.  On top of that, the Chief Product Owner began to push the teams toward the new design ideas.

Bob initially was brought in to fix another problem, but as an Agile expert he soon found people looking to him for a solution.  His first efforts involved engaging the designer in a release planning exercise that included allowing the designer to present her ideas to the team.  In addition the team was allowed to brainstorm design ideas and story reactions of their own.  The next step was to allow the whole group to create a merged or shared view of the work via user stories.  The goal was to allow the Scrum team as well as the designer to develop a shared view for what would become a feasible plan. 

We encourage you to take a look at the rest of Bob’s posts along with his many other very informative blogs.  For 15 years, he has been a pragmatic and passionate Agile trainer, coach and practitioner and has successfully leveraged Agile methods as the best way to deliver software value.  He states that, “While not being a silver bullet, they simply work better than anything I've tried.”  

Velocity Partners is an offshore software development company which uses a distributed Agile model that offers outstanding planning, accurate delivery and optimal business value. Our team is comprised of top Agile experts, consultants, and engineers who believe in not only meeting but exceeding our customers’ expectations. Contact us to learn more about how a distributed Agile model provides high-quality software development.

[nanchu]

Three Magic Words - Minimum Viable Product. Also Research.

The thoughts and opinions expressed below are purely my own and not of ThoughtWorks (my lovely employer). 

THE MVP

Congratulations! You've won! Here's your prize, your beautiful magnificent Minimum Viable Product! What? What's that you say? It's not actually what you wanted? Oh I'll just take this back then... Oh... oh you want to keep it? Your users like it? Well ok, here you go.

The MVP. I've heard this word tossed around so much on client projects but what does it really mean? The consultancy answer is - well, it depends.

It depends on what the client defines as success for that MVP. It depends on if you are building a completely new product or building on top of an existing product. What is the minimum set of features that will make your product viable (e.g. usable and produce business value) that you can then test and refine after release? What will make your product owner's boss(es) say "great job!"?

A MVP is a set of features that represent the solution to some hypotheses of user needs, market opportunity, and business needs. Ideally, the features that the client wants to build for MVP are really just the minimum ones that complement a few user journeys. Ideally  these have been validated by user research and perhaps some initial prototype testing. If they have not, then do NOT start development. Unless your client has all the time and budget in the world, then by god do whatever the hell you want.

Oh and one last thing, the MVP will never actually be what your clients say they want at the beginning of a project. It is only through the research, analysis, design, developement, and testing cycles that we will widdle away the excess pounds. What does this mean for the agile software development methodology? Estimating stories and creating a story backlog at the beginning of a project (especially to budget for that project) is preeeeeetty useless. 

THE STORIES

Story writing is a great way to capture requirements while building software. The problem with story writing is that it makes you forget. It makes your team forget that these features are hypotheses.

Stories are valuable as documentation to delegate tasks to your dev team. But at that level, when you are thinking about how interaction design translates into acceptance criteria, who's validating the original hypotheses in all that paperwork?

Sometimes a few features sneak into your development cycle without having had their hypotheses validated. Some stories turn out to be crappy stand ins or risk mitigations for actual valuable features that the client thinks is too expensive to build. You as a BA and/or UXD need to keep track of these and protect the client's MVP by always tying each story back to a hypothesis and asking is this really valuable for business. 

I don't believe the traditional way of writing stories is enough. "As a User, I want to be able to add items to my shopping cart so that I can keep track of my items" does not say anything about the real hypothesis and value behind what we are building. They are just words that our developers don't read when they have their heads swimming in acceptance criteria. And I find that many times we make these words up as we are writing the stories. 

THE PRODUCT OWNER

Every product owner will now and then have a moment, a defining moment during the middle of your development cycle when they really really REALLY REALLY want a particular feature or set of features built for their product. And it is your job, as a valuable team member of this software building project, to say "Well, have you validated this with research or testing?" Don't be a BA monkey and just capture requirements, and then ask your product owner to prioritize these stories. Do some wire framing/prototyping to test these features. Send out a survey to users! Anything! Show your product owner that you care about building software that is actually valuable. 

What do you do when your product owner says "No we have not done any research, but we can research/test this as part of the MVP"? As a delivery team, it is not enough to just agree and build it. It is our responsibility to document/track these risks and then help our client come up with a testing plan to validate these decisions after the product MVP launches. 

The challenge I've been battling recently is how to balance/cope with all the business constraints that funnel last minute decision making into feature designs that may or may not be huge risks for the success of a MVP. We are still chipping away at the constraints in order to provide the best user experience. I just hope that we can chip away enough so that our client can be successful post MVP.

[esstoosci-blog]

unit testing

Rich recently discussed unit testing, an important aspect of his coding practice (slides; sample code). So what is unit testing and why is it important? The idea of unit testing is to write a collection of tests in parallel to writing code. The tests are on units, defined as the smallest piece of testable code, and they confirm that the units are fit for use.

You can probably convince yourself that you should be doing unit testing by considering a single example. A researcher was forced to retract several high-profile papers after discovering that a change of sign in his code resulted in an incorrect determination of the chirality of a protein. If only he and his colleagues were in the habit of unit testing!

Other motivators includes that it's faster to unit test (the unit testing tortoise and the cavalier hare). It allows you to discover bugs while you're familiar with the code, and reduces the number of them. It allows you to reuse code more, in part by creating evolving documentation. It makes it easier for you to alter code, for example, for optimization and refactoring (here a connection to agile software development).

Thoughts on the form that the tests should take include that you could compute expected output for a simple input, a test case (a MATLAB video on making test data). You could do boundary analysis. You could compare to alternative computation (e.g. numerical). And for random numbers, you could consider their coverage (save, display or fix the seed). Lastly, make it clear what's being tested, and verify one condition per test.

Tools for doing it include xUnit and docTest. They can be used for organizing, running and interrogating unit tests. Here is another article on automated software testing for Matlab.

One person responded to the idea of unit testing with a soft jab, which is that one could imagine writing unit tests for unit tests, a kind of regress that most people didn't seem overly concerned with. Someone also pointed out that Matlab is less good than it could be in that some of the checks that one would associate with unit testing could be built in. The point was also made that you only want to test important things, not trivial issues such as wrongly typed inputs, and that you shouldn't consider the impossible task of checking things exhaustively.

[littlemissdebbi]

These titles aren’t available yet, but you may need to move quickly once they are. Agile software development may be rapidly moving into the mainstream, but that doesn’t mean the innovation in that field is slowing down.

Traditional ‘waterfall’ development may be out of favour on the startup scene, but we wouldn’t be surprised to see books about new ‘hybrid’ approaches (aimed at really large projects) in future, combining agile methods with their more established predecessors, although everything in the list below is pretty much ‘full on agile’.

[manishchhabra]

Requirement Analysis – A developer’s perspective

People that get between developer and customer have the best of intentions; they’re trying to let developers focus on writing code. But I’ll say that their job isn’t to write code it’s to deliver a solution.

Fire your Business Analysts Customers don’t write the stories and neither do business analysts, project managers, or development managers. I’d go so far to say that if you want to be “agile” and you’ve got a team of BAs then you should fire them all. Anybody getting between the developer(s) and the customer is stopping the developer from becoming the customer. Crucial detail will be missed and misplaced assumptions will go unchallenged. Sure, you’ll still get a product out the door but it will either be what was agreed (which is often different to what is actually wanted) or it will not be as awesome as it could have been.

Customer Interaction It is false economy to think you are saving the developer(s) time by taking on the requirements analysis on their behalf. It is essential for a developer to interact with the customer. It will take longer for them to appreciate 3rd hand in the requirements than the half day it would take to know them first hand and write them up themselves.

With Agile Development it is best to have developers on site because requirements cannot always be fully collected at the beginning of the software development cycle; therefore continuous customer collaboration is very important.

[techgropse07]

TechGropse deploys flawless apps for empowering businesses and making them pioneers of premium apps. It is the only organization in the market of mobile app development in Saudi Arabia that provides consistent free support for one year as benevolent gratitude.

[agilescrum]

There are still many open source kanban tools available, contrary to open source projects for Scrum tools that have mostly ended being transformed in a limited offer that supports a main commercial product. The simplicity of the Kanban approach has allowed open source software developers to create and maintain Kanban tools based on various platforms. This article lists pure Kanban open source tools.

[petrjanda-blog]

Agile way hints

I see the agile software development as the big step forward. All the IT market is globalized and adapting really quickly to new requirements. Successful software development team today has to be ready for that challenge and the agile software development is one of the ways which can give you exactly that. Six months ago I started to work on new project in brand new team. It was the big opportunity to bootstrap agile process from the team early beginning. However, everything didn't go as smooth as we wanted and after some time we found few things which could have been done better already from start. So let me share with you few observations i collected in last months. Think 100% done way ----------------- One of the key benefits you will get from properly used agile methodology is the really fast feedback. Everything is done in short iterations (regularly in 1 - 4 weeks) in end-to-end philosophy, which mean there is potentially shippable product at the end of each iteration. Personally I found this as the hardest step to becoming agile. When you consider something done, ideally there is no more time needed anymore, to have the feature ready for costumers. When starting with agile you will probably find yourself being somewhere around 90%. After the time the deadline approach and people will start to use your product. This will be the hard phase for you, because your bug tracking system will probably collect many of unfinished or non working features. So don't postpone part of the work in order to say something is done. Its not and you will realize that. Focus on actual stuff ----------------- Stop thinking about proper design of the full system before you start implementation. Stop building the 250 page documents or big charts trying to describe every edge case you can find while building your product. Focus on actual things and what is really necessary. Trust me, most of the time your documents will become obsolete even before you can use them. The requirements are changing really fast and this can be just a big waste of time. Of course there is the place for the planning in agile process. You need to think as most as possible in big picture and avoid tons of hour spent on refactoring your code later. What I am trying to say is that planning months upfront is more guessing, full of expectations which will probably not be valid after few months, may be the weeks. Test all the fu***n time ------------------ If you want to consider something really 100% done you need to have the tests. They will become your partner for validation, if you are still doing good and everything works as designed. To be even better work in TDD/BDD way. Outside in approach will help you sort your ideas and find out what is the core of thing you are gonna do. As the result you will get much cleaner code and more stable software which just works and do exactly what is expected. You will probably find lot of information about agile on internet, speaking about product backlog, daily scrum, product owner and other parts of the process. Yeah, of course they all are important, but the agile software development is much more, its a really different way of thinking about how the work should be done.

[velocitypartnersblog-blog]

Velocity Partners offshore software development company’s new Principle Agile Evangelist, Bill DeVoe explains that, “The 3 C’s are a core component of good agile implementations. And making sure that we focus on delivering all 3 – especially our conversations – can help an agile team reach even loftier heights.”  He reminds us all that even if you have been practicing Agile for years (or if you are new to the practice), it is good for all practitioners to review or learn the “3 C’s.”

The 3 C’s were defined by Ron Jeffries in 2001 as the card, conversation, and confirmation.  The card started out as a 3 x 5 card, and the small size ensured it kept the story short and concise.  The evolving format focuses on: As a <role>, I want <some functionality> so that <I get some benefit>.  While it is not necessary to follow this exact format, it is a good starting point especially for Product Owners new to Agile. 

The next C stands for conversation and typically gets started when a developer reads off the card in order to begin a conversation about it.  In most cases, it is the Product Owner who begins to answer questions and gets the dialogue going regarding the story.  Bill reminds Agile practitioners that, “Conversations are the backbone of agile (if you check the Agile Manifesto, you’ll see that three of the four values deal with communication).”

Confirmation is the third C and involved the acceptance criteria.  This included the team’s consensus of when the story was complete as well as answering questions such as what should the software do when finished?  In some cases the acceptance criteria was written on the back of the card as a way to remind developers what the system should do. 

We encourage you to visit Velocity Partners’ website to learn more about our professional nearshore software development services. By combining quality software development and staff scalability, we provide our customers with optimal business solutions.  

Velocity Partners expertly delivers nearshore (Western hemisphere) software development services using a distributed Agile model that offers outstanding planning, accurate delivery and optimal business value. Our team is comprised of top Agile experts, consultants, and engineers who believe in not only meeting but exceeding our customers’ expectations. Contact us to learn more about how a distributed Agile model provides high-quality software development.

[la-principessa-nuova]

when big, traditional companies do agile, they don’t really do agile, they do spry

bc they’re not particularly agile, but they’re much more agile than you’d expect them to be for their age

[nanchu]

Pairing the Agile UXD to the traditional BA-Dev-QA Agile Triforce.

TL;DR Being a UX Designer is complicated.

Being a UX Designer on an agile software development team is akin to a drunken mechanical bullride at that western theme bar. Ok maybe not. But I think I'm qualified to ride one.

For one thing, we have so many different skillsets that it's always really hard to know exactly how to staff us on projects without first knowing what each designer does.

That being said, from my experience on agile software development projects (at least at ThoughtWorks) I've seen the following patterns:

UXD teams are staffed to counterbalance our skillsets - as being more on the business side with BAs, or more on the dev side as Visual Designers/UI Devs or as researchers. HOORAY PAIRING! or TRYING! (what happens when three people pair)

As projects progress and we go into delivery mode, we tend to get more and more specialized in our roles and division of responsibilities. Good things and bad things can come out of this. 

Good thing: Divide and conquer allows us to get work done faster. I can focus on IA and ID in story writing while you focus on UI dev / implementation of visual design.

Bad thing: You become too siphoned from your team mates and could end up having no idea what the other person is doing.

Most of my experience at ThoughtWorks has been with small agile teams where I play UX/BA and I am paired another UX/UI Dev or a researcher. 

What the hell is a UX/BA?

I joined ThoughtWorks 2 years ago initially as a Business Analyst (because we didn't have a UXD practice yet) and I received the BA training at our awesome JC program in India. As BAs we learned how to:

understand business goals 

capture features/requirements

discover user scenarios / acceptance criteria

write stories

plan iterations

prioritize/negotiate stories with clients and our dev team

Afterwards I was staffed as UXD on projects and leveled up my skills in:

product design

interaction design

information architecture

user research

visual design

UI dev 

In understanding both sides of the roles, I have been staffed as the UX/BA. This did not necessarily mean doing the work of two people, but moreso helping make the collaboration easier on teams. However I have found the UX + BA process more streamlined when you are able to be both UX and BA. For example, I can understand how to prioritize and vertically slice features into stories, which helps me strategically think about how to design for these clusters of stories in each iteration rather than get overwhelmed and try to design the entire app in one go. There is a time and place for high level design visioning, and it is not at the story level.

UX and BAs have much in common, especially in the realm of product design, business analysis, IA, and ID. But oftentimes we butt heads if we don't understand how the other works.

I asked some of my colleagues for their experiences in pairing with UXDs/BAs. Here's some examples of how these pieces could fail to fit together:

When the UXD is trying to ideate and design features in wireframes, the BA says "that's extra scope", "these wires don't match up with what our stories define as requirements", or "you've forgotten to design for xyz scenarios".

When the BA gives UXD a story to design for, the UXD says "there's way too many acceptance criteria in here", "how does this fit into my design?", or "there's weird scenarios in there that we don't need to design for".

UXD not being able to deal with a BA's backlog

BA not being able to deal with the uncertainty and oftentimes lack of deep analysis on a UXD's sketch to code process

UXD and BA not agreeing on how to assign value to a story for it to get prioritized

The list can go on. I'd like to hear your experiences here.

I believe that these failures are not a failure on our agile process, but rather a failure in communication and knowledge gaps. The more BAs and UXDs reach out to each other and learn about each other's processes/skills, the more empathetic we can be and help each other find a middle ground when it comes to differences in our workflows. 

One easy trick to start with - talk to your BA / UXD prior to the start of a project about your curiosity in what they do and discuss their processes.

What if we don't have a BA for the UXD to pair with? A.K.A. Who are those "pesky" QAs?

When there are no BAs, I have had success pairing with QAs to write stories with. (Again these are small agile projects where I doubled up as BA). QAs are amazing creatures. They are the beautiful magical unicorns of the Forbidden Forest! Ok maybe not, but have you ever met a fire juggling unicycling QA who will write stories with you like no tomorrow and write you a fully automated test suite at the same time? I have. I was fortunate to pair with Robin on my last project, who wrote a great blog post about his experience in doing BA work as a QA. 

ok so this picture isn't actually of Robin. I have no pictures of Robin. So I stole one off t3h googles. But this is what Robin basically looks like. Every day. Minus the weird 90s tie dye outfits.

We constantly paired on analysis for our stories. Robin helped me think of all the possible scenarios (things only a QA would think of! Those crazy magical unicorns.) and gave great input on interaction design for each scenario, especially for error handling and validation.

We had a sweet checklist for each story before moving them to "Ready for Dev"

Descriptive Title

Acceptance Criteria

Error Case Descriptions

Links

Inputs & Outputs

UI Screenshots / Mockups

Styling

UX/BA/QA/Dev input

One caveat. If you are a UXD and you find yourself in a situation like this where you get to pair with a QA (or a BA), don't be shy in pushing back and saying no to designing for every scenario that a QA or BA will think of. Some scenarios may not be high priority and it's ok to design for them later in a separate story.

OK great! Now how do I pair with Devs?

A good starting point in pairing with devs is learn to write some code. If you are the UXD who is responsible for making sure design gets implemented, you need to learn some HTML/CSS and even HAML/SASS (then you can impress those devs with the shiny new toys). Otherwise you will have to take some time out of your day to sit with the devs after they have developed most of the functionality of a story. Work with them on the UI polish by telling them what you want, and watch them code and update the view on their localhost.

Even when I play UX/BA on a project, it has been helpful to know code for deskchecks with a dev pair. If I see that the design is a bit off, I can sit down with them and spend 10 minutes to tweak the CSS. It's even more helpful when I understand the client's existing SASS architecture and just tell the devs which classes to use in their HTML so they can easily pick up existing styles for elements on their page. How much time you can save there if you just learn some code?

Thiiiiiiiiiiiiiiiis much!

But I already have someone on our team who can handle the UI Dev work! A.K.A. why don't our developers know CSS?

If you have someone who's great at implementing visual design on your team, great! Maybe they are a dev who knows front end, or maybe they are another UXD who can code. The challenge in pairing now becomes really to keep them in the loop on the prioritization of stories in your pipeline. Getting their input in interaction and visual design is easy. Making sure they don't get swallowed by the dev team and become just a dev monkey is harder.

Set expectations for your dev team that they are responsible for writing good markup and CSS, or at least learn. You'd be surprised at some of the knowledge gaps your brilliant developers might have when it comes to front end work. Your UXD pair who can code should not be the bottleneck to your entire dev team on UI cleanup. Also this takes your pair away from you when it comes time to work on interaction/visual design. And we all know what happens when you don't pair.

[cinderellascrummaster-blog]

Velocity Is Not Value

Story points are a tool for communication and planning, not a measure of success.  Yet, because of…

View Post

[syndicode]

Writing correct User Stories

A user story is a tool used in Agile (and not only) software development and is an informal description of one or more features of a software system. It’s usually a vital part of the software development implementation plan you follow. Writing correct User Stories is a powerful technique th...

[adventuresincoding-blog-blo-blog]

Why do so many software projects fail?

An excerpt from Dreaming in Code, talking about how some software projects become enormous black pits that never deliver a finished product: 

It's tempting to view the multitude of monster projects gone bad as anomalies, excrescences of corporate and government bureaucracies run amok. But you will find similar tales of woe emerging from software projects big and small, public and private, old and new. Though details differ, the pattern is depressingly repetitive: Moving targets. Fluctuating goals. Unrealistic schedules. Missed deadlines. Ballooning costs. Despair. Chaos.

The recipe for disaster. I know this feeling all too well. It's a good lesson for product managers, project managers, CTO's, engineers, CEO's, and anyone else who has a direct role in the building of software.

So what's going on here? Why do so many projects have moving targets and missed deadlines? How do we handle this? What do we do when new requirements start flowing in that have the potential to take us off track? 

I think part of the problem is people fundamentally not understanding you cannot add something new to the project without either taking something away or extending the deadline. In agile product management (or agile software development) we solve this issue with the concept of a product backlog. We use this to keep track of all wishful future features and products. This is where we send all the nice-to-have's. This is where all new feature and product ideas go after the initial project (sprint) has been started. This is where we prioritize what is to be built next. This is what helps keep the project within scope and on-time. So when the CEO has some epiphany in a dream you let him know that we can add it to the product backlog and it will be completed in the next release. Or if he insists and wants it now, you ask him what current feature we can drop from the sprint to ensure we deliver on time. And if he doesn't want to drop anything you let him know we need to extend the deadline. And if he doesn't want to extend the deadline you let him know that we need to call up Clark Kent because this simply isn't humanly possible.  

Another part of the issue is that we often expect too much out of our product. We want it to be perfect. We want to show off and so we have this desire to build everything under the sun into the first release. Which is completely wrong. The proper way to build software is in quick and iterative releases, leveraging user feedback as much as possible, as soon as possible. The worst thing a company can do is spend months and months if not years in stealth building this grand product and then releasing it just to find out it's unusable and no one likes it. (A recent example of this may be the Color app which raised $41 million and flopped. Or how about BlackBerry with their new operating system, oh wait that still hasn't been released yet has it.) To solve this one needs to build a minimum viable product (MVP) and get it into the hands of users. Then study usage patterns to understand what features are useful or useless and adjust as needed. Once done there, add a few new features from your product backlog that will really solve people's problems and add value. Then, again, study user interactions and keep continuing with this process. If you don't do it this way you are going to miss out on a lot of invaluable learning and you may be taking on a huge and unnecessary risk.  

That's all I have to say for now (I could go on for another 50 paragraphs, but no one would want to read that). For those who are interested in the terms sprint and product backlog check out the scrum and agile development methodologies. If you have any questions about them please feel free to contact me. And remember the lesson from above: poor planning, constantly changing requirements, ever adding more features (scope creep), moving targets, etc. all lead to missed milestones, inflated costs, internal strife, and eventual despair. It's a recipe for disaster and if it's happening in your organization speak up. And if no one's listening, run, run fast and run far because the human waste is about to meet the turbine blades.