Agile Development Business | 2017-10-18
Aspects of agile development I believe in and my experience thus far
I have been a part of 3 major teams that either used waterfall, agile or other, some have been better than others, but communication (cross-team), documentation (requirements, bugs, edge cases to watch out for), and working as a team (helping each other) have been the most important. Below I describe each team and what they did as a team, whether it worked or didn't work
Consulting Work - FinnSisu
Small project with a estimated deadline. This dealt with building a website that integrates with an in-house Point of Sale system. Testing was completely on-my-own and testing had to be completed 4 hours from where I was living. This project was waterfall because I did not report my progress to a team. When I visited the office, I met with the owner and described my current state and what date I'm shooting for to release these website.
Web Designer at Daktronics
The project was small in scope with monthly deadlines. Cross-browser emails are tough, require a lot of manual testing (even when using Mailchimp) and it's tough to judge when you're completely done. Worked with designer and business to iterate and decide final copy. I met with my manager and she went through and made final decisions for styles used, made suggestions, and iterated. Deadlines weren't shared, neither was final copy, and one email campaign for a newsletter didn't send on time.
Pro tip: If it's a hard deadline, make a calendar appointment for a release and make a quick meeting about what's going up, when.
Developer at Red Wing Shoe Company
Large projects with deadlines, milestones and deliverables, but QA waited until the end of the project, with little guidance of how they could test the project, even on the night of release. Weekly status updates (one-on-one) with my manager and every 2-3 weeks the entire group would get together and go over high level details. Development leads took a lot of the responsibility on the project's success.
Full Stack Developer at Carsforsale.com
Large complicated projects, drawn out for a long time. Daily status meetings with the team of 6-7 developers on what we each worked on. A lot of this was for the manager, to keep a tight leash on understanding what we’re doing, otherwise he didn’t know. Dev QA was mostly done and QA had to be taught what to look for and what the application used to do. Strangely, they emailed the entire company when they found a bug, in Red, all caps. Fear of bugs was common, requirements were limited, and time to develop took longer because of those two things.
Pro tip: Talk to the developer about bugs, don't email 200 people.
Large projects, broken down into singular pieces to develop and test. Fully agile software development, but every team does it differently. Standup is very useful for offshore QA and developers located in another city or WFH. It’s natural and easily allows us to shift on a production bug, or help other members of the team if they need. Agile works well, when done right!
"We're just getting into Agile and I don't really understand it"
- The term 'Agile' is everywhere. But don't let it scare you if you're not familiar to it. It's software developement with planned work, regular deliverables, status updates, and releases (if business appropriate).
- Software teams love getting done what is important. Without accurate deadlines, goals, or status updates it's easy to work on something that higher ups don't deem it as crucial.
- On large projects, documentation is completed before stories are written. Sometimes it's a "3 in. binder" that explain what you have to do and the necessary requirements. That's old school and uncessary. While a wide understanding of current goals and future implementation is crucial, allong with a remote location for storing files, it's important to keep things simple.
If the Acceptance Criteria doesn’t make sense, then the story has too much. I’m talking pretty granular stories. Here are a couple of examples:
- Tablet Update - Setup data call for Earnings data - In house QA (b/c of internal tools)
- Unsubscribe Alerts Page for One-time Email alerts
- Unsubscribe Alerts Page for Recurring Email alerts
- Watch out for too broken apart stories that can't be developed or tested separately. Development and QA may spin their wheels with this (I already tested this)
Grooming is a way for the team to estimate complexity, potential roadblocks, difficult portions, testing effort, etc. Points aren't equal to time it takes, it's equal to effort it takes.
- Estimate the effort it will take by raising your hands with your estimate (1-21 usually, any larger is a project)
- Document QA and Dev areas to test or watch out for that we talk about
- Don't be afraid to ask to split stories apart if it's too large
- If there are blocking items, PM will follow up on each story, assigning them to the appropriate team if necessary.
Weekly, your client/PM and team members will decide together which stories and how many points they WILL get done. This estimate is based on:
- General point completion count (last week we completed 54, this week 60, a couple months ago we were at 70) - Find a rough average
- Who will be out the next two weeks and how that will affect the point commit
- Out all week could reduce it by a story or two, for a ½ day, it shouldn’t matter
- How much QA will be needed? Are stories quick for dev, time consuming for QA?
- Avoid having multiple high effort QA stories because they also need time for regression and other stories in the sprint.
- What stories can dev can turn around quickly for QA to start by the 2nd or 3rd day. Plan a couple easy ones
- It’s useful for your team members to understand if the two of you are working on similar items (and conflicts that will happen later on)
- Allows you to be up-front about blocking items, if you keep saying X is stopping progress because Y, someone will listen.
- But don’t wait for stand-up to say these concerns, email the team right away if it is a concern, or you need someone else's help.
- A blocking item may mean pulling this story out of the sprint, commenting out your code with an explanation of progress made, and committing it so you don’t lose progress.
- Yesterday, I worked on… Today, I am working on… Nothing is blocking me.
- Keeps you accountable for long stories. I try my best not to have stories last 3 days or more, if it looks like it’s getting close, I get help when I struggle for 15 minutes or longer. The sooner you ask for help, the less time you waste.
- When stories are complete for the sprint, QA has tested them and marked them ready for demo, it’s time to work on something your excited about.
- Don’t have to stand up, but it keeps things moving quickly. This progress meeting should not take more than 5-10 minutes, if you need side conversation mention it (or ask them to stay on the line if they aren’t in the room); don’t waste everyone's time.
Being part of a Team matters
- Clients or PMs have emergencies and developers priorities get switched when
- We need this right now, drop everything, oh wait, we need this issue resolved.
- Very tough to effectively code without a plan
- Members of a team are in it together
- Asking for help (after 15 of getting stuck then ask them a clear and concise question) and assist team members when they need it.
- Ideas if you finish your work
- Ask QA if they need help
- Assist with stories other devs have, check if one dev has 2-3 stories and see if you can grab that one off their queue.
- Personal objectives you would rather work on?
- Again, Why??
- For a year, I thought getting stuck and figuring it out on my own was normal.
- Tough to ask questions cross-team, when they have deadlines, bringing it up as a blocking item and people will listen. If you casually mention it to your boss, it’s not a big deal. But if progress is impeded and will hurt our ability to make a deadline, it suddenly matters.
- Prior to Markit, I had
- Stand up for what you're working on. Agile helps