Orientation: Making the Change to the New SDLC

This guide highlights key changes in behavior, practices, and values expected as we modernize the SDLC. Not all will apply to everyone; it’s possible you already follow some of the processes detailed here, or might have to make only slight adjustments. Below we compare our previous methodology with our new expectations.

SDLC 2.0 lets us realign our organization, and ourselves, with current industry norms in methodology, tools, and values. Throughout IT, development has evolved to be more agile, user-centered, and collaborative. In addition, AITS has introduced new roles and tools that need to be reflected in our process. While change always involves some cost, SDLC 2.0 aims to spark numerous improvements, both for the organization and ourselves, including:

• More efficiency in designing better and more satisfying products
• Improved teamwork, with the opportunity for true collaboration
• Greater clarity in what is expected from team members
• Enhanced individual professional growth that stems from adopting industry best practices and tools

What changes will I see with SDLC 2.0?

Process

How we work together – role participation, expectations, milestones – will be different with SDLC 2.0 (see the Process and Roles sections for details). Participation will change to reflect closer involvement of the core team and client. For example, if we graph a role’s level of involvement, we might see a stark contrast between the old process and new:

Having a shared understanding of defined phases and milestones should also help everyone accurately understand a project’s health and progress. In addition, you can expect:

• A different project rhythm, with more time and effort dedicated early to discovery, design, and testing.
• Earlier involvement of team members like QA and Accessibility Specialists, so they are involved in product decisions.
• More involvement of clients and end users, particularly through usability testing.
• Updated milestones and check-ins, with an emphasis on capturing timely points of agreement, without false consensus or premature sign off.
• Flexibility and empowerment to adapt agile/lean/design-centered methodologies as desired.
• Wider understanding and use of the organization’s development process.

Old thinking	New thinking
Our process is linear, like an assembly line.	Our process is iterative and may fold back on itself in response to feedback and new insights.
A project is a single, monolithic unit.	Projects may be divided into multiple phases, with multiple deployments if desired; projects can be organized into sprints. Teams can define Minimum Viable Products (MVPs) and gradually build and test enhancements.
Testing happens at the end.	Testing and evaluations (client, users, QA, accessibility) happen throughout the process.
“We use a waterfall model.”	We adopt modern, IT-native methodologies than are proven to yield better, more cost-effective solutions.
“I don’t really know our process/I didn’t know we had a process; I do what I’ve always done.”	“I understand AITS’s process, and can use its common vocabulary to clarify my project’s status.”

Activities and norms

Collaboration doesn’t just happen; it must be encouraged through activities and shared norms (see the Process narratives and Role descriptions). Development should now reflect:

• Less siloed work, and more collaboration/team design and discussion.
• More prototyping and early testing of ideas.
• Co-authorship, instead of hot-potato-handoffs of deliverables.
• More emphasis given to creativity and innovation.
• Greater appreciation of how all roles complement one another.

Old thinking	New thinking
Team members work individually most of the time.	Discovery, design, building, and testing are all team activities; team members can be sounding boards for one another.
Analysts alone develop requirements with clients.	Requirements can be refined by any team member, and can stem from end users via testing or interviews. Product specs are a joint document.
“We don’t design/build until all the requirements are set in stone.”	"We know that changes will come, and some of our assumptions will be proved wrong. Our process means we can adapt.“
In our “assembly line” the last one to touch something can make any changes they want.	Alterations from team decisions are discussed. If something “doesn’t work well’ (a requirement, design, implementation), there should be a discussion beforehand. No one should be surprised when they view the end product.
Meeting project timelines is the most important goal.	While meeting timelines is important, we care about innovation, efficiency, and products that please end users. We may divide projects into multiple phases to ensure quality.

Deliverables

Deliverables shouldn’t exist if they aren’t efficient, helpful, and appropriate. They are not ends unto themselves; they need to be clear and useful for the person/group they are created for (See the Deliverables Index). We expect:

• Different artifacts – no more cumbersome, text-heavy doorstops that are hard to maintain. Annotated visuals, diagrams, project boards, checklists, user stories could all be involved in a project.
• More iteration and roughs of deliverables.
• Content shaped by the consumers of the deliverable, so they are clearer, relevant, and lightweight.
• An easier time digesting and maintaining deliverables, saving everyone’s time.

Old thinking	New thinking
Deliverables are long and formal.	Written deliverables should be light and easy to read. Some deliverables aren’t written documents at all – they are working prototypes or code.
“I have to fill out all these templates.”	“We create deliverables that provide value to our team members and future colleagues. If a document has no value we don’t create it.”
“I don’t have to document everything; it’s in email/meeting notes/our minds.”	“People forget and are prone to misunderstandings; recording decisions helps everyone.”
The first draft of a design will be revised once, and then it’s done.	Designs require multiple iterations and revisions. Iterations can’t go on forever, but it’s naïve to think everything will be finalized with only one or two versions.
The product spec is the only artifact that matters.	The full measure of a product is distributed throughout the product hub. The spec is only a part.

Tools and habits

Previously, tools might be limited to a file share location that teams may or may not use. Today, we’re more open to specialized tools that make us more efficient and remote-friendly. Teams will see:

• Modern toolsets that are native to web and app development.
• A standardized Product Hub to serve as a project’s basecamp, containing project management information, team communications, overviews, history, backlog, drafts, requirements that can be easily found. No more requirements hidden in emails, or 150-page specs that are never used.
• More opportunity to adopt current technologies, aligning us with external, industry-standard toolsets, which in turn keeps our staff current and competitive within the broader IT world.

Old thinking	New thinking
All documents are in Word or Excel.	Deliverables can take multiple formats; the form matches the intent and the audience, and multiple tools can be used.
There’s not a single starting point or hub for product information.	Every product/project has a basic hub for specs, team communication, project management info, etc.
“We should keep doing things the way we did 15 years ago.”	“We look at what other, outside organizations use for effective communication and development, and adopt them to make ourselves more efficient.”
Team communication occurs in email or meetings.	Team discussions happen in the project hub.

Team interactions

Teams who are clear on their joint expectations, roles, and process can expect greater efficiency, trust, and confidence. As SDLC 2.0 is adopted, we expect teams to find:

• More emphasis on discovery and design means less chance for major changes/scope creep along the way, when it’s harder to change. This, in turn, means more efficiency and less frustration as projects progress.
• More clarity on who is doing what (Pre-flight) and what roles entail (role descriptions), which lessens the chance of miscommunication.
• More collaboration can enhance one’s own professional development.

Old thinking	New thinking
In a project with no assigned PM, PM tasks aren't done.	The team discusses and assigns these functions amongst themselves.
One team member can make decisions independently on how something works.	There should be team consensus on features and experiences.
“I don’t need to know what that person does; it doesn’t affect me.”	“Even if I don’t work closely with them, I know what they do and how it fits into the overall process.”
“I’m in a rush, so I’m going to change the interface or requirements on my own.”	“I’m going to loop in the right roles so they know what is going on.”
Team members rarely communicate questions/concerns across roles during a project.	Team members frequently discuss questions/concerns across roles throughout the project.

Better outcomes

Modern methodologies have been adopted because they are proven to lead to better products, interactions, and decisions. As we transition, we expect:

• Better, data-driven solutions, as early testing and feedback increases.
• More accuracy, as client and user involvement reduces the chance of missing the mark with a feature or solution.
• More user acceptance and satisfaction, as ideas are refined and given real-world evaluation.
• A faster path through testing, because issues have been addressed earlier.

Old thinking	New thinking
Client and user feedback is provided mainly at the end.	Clients and users are involved throughout.
Clients speak for users.	User testing allows for direct input by users.
QA and accessibility testing occur at end of development.	QA and accessibility specialists have an opportunity to identify and solve issues earlier, in design and build phases.
Our revision phase might get condensed, meaning important features or design quality are jettisoned due to time pressures.	Refinement and testing throughout provides more time for troubleshooting, so we are not struggling at the end.
What a product looks like isn’t that important.	Users evaluate credibility and professionalism on what they can see. Our apps need to look modern and be easy to use.

Dangers and pitfalls

Taking a more agile, iterative approach yields benefits, but there are also ways this methodology can be misinterpreted or misused.

1. Iteration should not mean infinite revisions. Iterations should show forward movement, and not be used to justify last-minute changes.
2. Lack of timely feedback A faster revision cycle doesn't always mean team members or clients actually provide feedback that is requested. It's easy for people to put off really engaging with draft content because they believe they can speak up later.
3. Possessiveness Some people may be used to having considerable freedom and decision-making authority in how they operate. Being a "one-person band" might be difficult and inefficient, but it's also familiar, and might be a difficult position to abandon.
4. Old habits die hard. This SDLC shares terminology and steps with the previous version, but they should not be conflated.

Conclusion

Adjusting to a new system entails costs: time to learn a new process, tools, and deliverables. Leaving anything familiar can seem daunting. New practices will need to be fine-tuned over time. However, adopting a more streamlined, nimble process benefits AITS through improved efficiency and products. More importantly, it improves our daily work environment by providing clear expectations, consistency across projects, smoother project interactions, and experience with modern, valuable skillsets. As you begin utilizing this framework, please share your feedback and experiences so that it can continue to evolve and serve everyone’s needs.