Difference between revisions of "Agile mindset and software development"
| Line 1: | Line 1: | ||
| − | |||
| − | |||
=Agile Development Workshop / Scrum= | =Agile Development Workshop / Scrum= | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Definitions== | ==Definitions== | ||
| − | * '' | + | * ''K'' In late 90s originally defined as "lightweight processes" but changed to Agile. |
* Evolved in response to waterfall planning where everything was mapped out from beginning to end; focus on allowing for adaptable change to conditions. | * Evolved in response to waterfall planning where everything was mapped out from beginning to end; focus on allowing for adaptable change to conditions. | ||
| Line 60: | Line 36: | ||
* It's like Scrum but... | * It's like Scrum but... | ||
| − | '' | + | ''K'' |
* Moving through system as quickly as possible | * Moving through system as quickly as possible | ||
| Line 76: | Line 52: | ||
==Experiences and Questions== | ==Experiences and Questions== | ||
| − | '' | + | ''J'' Past experience of sticking to one implementation road map even if it doesn't quite work/fit. |
| − | '' | + | ''C'' "Coding your way to victory" one definition. Outside of these systems, what are the questions, checklists, systems that actually makes it Agile? |
| − | '' | + | ''K'': Instead of focusing on strict adherence to any given system check if it works for you, how does it fit with the goals of the client/customer/stakeholders? |
* Agile relies on good quality code, | * Agile relies on good quality code, | ||
| Line 90: | Line 66: | ||
* Again the human side-developers need to communicate with users/product managers/clients. | * Again the human side-developers need to communicate with users/product managers/clients. | ||
| − | '' | + | ''M'' Summary: the main focus of Agile is one of good communication and efficient integration. |
| − | '' | + | ''K'' Get something out there, maybe it's not good enough, but customers will provide feedback. |
| − | '' | + | ''N'' what about use cases or a walkthrough? How is Agile embedded in project conversations, how does it increase efficiency and communication? |
| − | '' | + | ''M'' how does it work in a solo context? |
| − | '' | + | ''K'' it does work in a solo context, and is optimal for smaller groups < 7. |
| Line 114: | Line 90: | ||
* Have collected many "user stories" | * Have collected many "user stories" | ||
| − | '' | + | ''K'' One part of process is to collect user stories from stakeholders. |
* Interviews of groups, user stories turned into feature list. | * Interviews of groups, user stories turned into feature list. | ||
| Line 120: | Line 96: | ||
* Currently in process of starting to write code. | * Currently in process of starting to write code. | ||
| − | '' | + | ''K'' What's relevant at this stage is to identify the MVP--what's the Minimum Viable Product? In order to prioritize core functionality need to really understand user needs. |
| − | '' | + | ''Y'' How do you divide and delegate tasks? |
| − | '' | + | ''K'' This is where you get into the different types of Agile systems defined above. Usually this relies on people taking responsibility for tasks and writing high quality code/doing things well. |
| − | '' | + | ''K'' In an Agile workflow a hierarchical organization may not be compatible |
| − | '' | + | ''J'', ''Yesenia'' has a 1.0 version of something that was created, but doesn't necessarily fit current goals, needs. Do we start Agile using existing crap, or start afresh? |
* Is Agile something that can be retrofitted into an existing project that wasn't developed in that manner? | * Is Agile something that can be retrofitted into an existing project that wasn't developed in that manner? | ||
| − | '' | + | ''K'' The bigger and worse off the inherited project is from the start, the harder it is to adapt an Agile workflow into the project. |
Typically these cases come in two flavors: | Typically these cases come in two flavors: | ||
| Line 142: | Line 118: | ||
A big red flag in these circumstances is that there are no well defined boundaries, which may lead to huge scope creep. | A big red flag in these circumstances is that there are no well defined boundaries, which may lead to huge scope creep. | ||
| − | '' | + | ''P'' how do you interact with clients? |
| − | '' | + | ''K'' First build your MVP, then show the client in stages every two weeks so that they can provide feedback. During the process add features, and/or address bugs. |
==Timelines== | ==Timelines== | ||
| − | '' | + | ''T'' How do you manage timelines? |
| − | '' | + | ''K'' Kanban approach: you can collect metrics based on history of the rate in which you complete stories/features. |
| − | '' | + | ''K'' Scrum approach: you can estimate number of story points over a period of time and then once you have experience you can fine-tune that estimate. |
| − | '' | + | ''M'' So how does this work within a set timeline? |
| − | '' | + | ''K'' having a set "triangle", (an inflexible timeline/ scope/ quality of product) will create problems when using an Agile workflow. It 'will' create issues with the ability to produce quality code. With Agile you try to focus on maximizing the quality of your code. Instead an Agile methodology says that you will get 'something' by a 'certain date', it will have 'some features'--maybe more or less than what client wants. |
| − | '' | + | ''O'' How do we get the feedback loop right, fine-tune it? |
| − | '' | + | ''K'' Many people get fixated around end product delivery, but this kind of thinking can be dangerous within an Agile context. |
==Agile in Other Contexts Beyond Software Dev== | ==Agile in Other Contexts Beyond Software Dev== | ||
| − | '' | + | ''O'' Can you apply Agile in other contexts beyond software development? |
| − | '' | + | ''M'' Relates to process of writing an essay in high school. When you're working in a small group, the ability to self assess is important. |
| − | '' | + | ''K'' Even working alone without being able to interview a client/audience, you can still put yourself in the shoes of the end user. Works really well for processes that are amenable to change and amendment, but not so great for building physical, end results focused things like a skyscraper. |
| − | '' | + | ''O'' Can Agile be used for community organizing? |
| − | '' | + | ''K'' Absolutely. Relates experience developing software for a non-profit embarking on a campaign. Iterative thinking vs. traditional end focused process: deliver what the customer wants now, instead of focusing on delivering something that they wanted and planned 1 to 2 years ago. Try to pilot your project, frequently adapt and respond to changes. |
| − | '' | + | ''T'' Related experience working with policy think tank that publishes reports. Needs to work with communities on the ground to update/fine-tune goals and release cycles for reports. Works in an Agile manner, though policy analysts wouldn't see it that way. |
| − | '' | + | ''K'' works well with documentation, wikis blog, information that needs to be freqquently updated--living documentation. |
==Drawbacks to Agile== | ==Drawbacks to Agile== | ||
| − | '' | + | ''C'' What about Agile and security? |
| − | '' | + | ''K'' Agile workflows create issues for the security focused, and for UI designers. UI design usually has a fixed idea of the end product. Security experts would typically emphasize that security needs to be a foundational part of a project at the beginning. This is a known point of contention between proponents of Agile and security folks. You need to understand security issues and risks from the beginning of the project--i.e. don't make security part of an Agile workflow. |
==Agile, Education, Implementation== | ==Agile, Education, Implementation== | ||
| − | '' | + | ''O'' are they teaching Agile in high school? |
| − | '' | + | ''M'' at Oakland Tech they aren't explicitly teaching Agile or CI (Continuous Integration), but they are imparting the concepts implicitly. |
| − | '' | + | ''C'' senior year at Oakland Tech they're learning Python, junior year Java. |
| − | '' | + | ''J'' what about testing, CI and its implementation? How does one wrap their head around a cultural issue, write tests and then leveraging tools to implement it? |
| − | '' | + | ''K'' this is a quandary that other organizations--much larger, and more well funded--are struggling with, don't feel bad. |
==Tools, No Pain No Agile??== | ==Tools, No Pain No Agile??== | ||
| − | '' | + | ''K'' From a tool standpoint you need a way to track changes, and version changes (i.e. Git) |
* CI works hand-and-hand with Agile, if something is painful and takes too long, do it more often! | * CI works hand-and-hand with Agile, if something is painful and takes too long, do it more often! | ||
| Line 212: | Line 188: | ||
==Summary/Takeaway== | ==Summary/Takeaway== | ||
| − | '' | + | ''K'' The goal is to find an Agile process that works for your team at this moment and context. Not a rigid adherence to some set process or tools. However, it's advisable to stick with one flavor of Agile first before tweaking and mixing them. |
Latest revision as of 22:23, 26 November 2018
Agile Development Workshop / Scrum
Definitions
- K In late 90s originally defined as "lightweight processes" but changed to Agile.
- Evolved in response to waterfall planning where everything was mapped out from beginning to end; focus on allowing for adaptable change to conditions.
- Back in 2000 Agile was a radical idea that scared developers and managers.
- Nowadays pretty widely accepted. Believes that Agile is more humane than other types of project management processes.
- Development is part of design (or is it design is part of development?) process, each developer has to think of how each part will fit into the whole. Focuses on communication/connection.
- Core focus: human oriented
4 Pillars
- Individual and interaction over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over customer negotiation
- Responding to change over following a plan
The Different flavors of Agile
Scrum
- Daily meetings, prioritized backlogs
- A number of rules and practices, but just doing them may or may not work. Need to see how it fits into your particular workflow
Scrumbutt
- It's like Scrum but...
K
- Moving through system as quickly as possible
- Very flexible
ScrumBAN
- Half of each
Extreme programming
- Pair programming
- Frequent face-to-face meetings with customers/client/stakeholders
Experiences and Questions
J Past experience of sticking to one implementation road map even if it doesn't quite work/fit.
C "Coding your way to victory" one definition. Outside of these systems, what are the questions, checklists, systems that actually makes it Agile?
K: Instead of focusing on strict adherence to any given system check if it works for you, how does it fit with the goals of the client/customer/stakeholders?
- Agile relies on good quality code,
- Need to be responsive, but have a solid base.
- Again the human side-developers need to communicate with users/product managers/clients.
M Summary: the main focus of Agile is one of good communication and efficient integration.
K Get something out there, maybe it's not good enough, but customers will provide feedback.
N what about use cases or a walkthrough? How is Agile embedded in project conversations, how does it increase efficiency and communication?
M how does it work in a solo context?
K it does work in a solo context, and is optimal for smaller groups < 7.
Use Cases & Process
Jessie's Project
- 3 person development team
- Many sources of customer feedback; talking to users for features/requirements.
- Uses off-the-shelf software.
- Have collected many "user stories"
K One part of process is to collect user stories from stakeholders.
- Interviews of groups, user stories turned into feature list.
- Currently in process of starting to write code.
K What's relevant at this stage is to identify the MVP--what's the Minimum Viable Product? In order to prioritize core functionality need to really understand user needs.
Y How do you divide and delegate tasks?
K This is where you get into the different types of Agile systems defined above. Usually this relies on people taking responsibility for tasks and writing high quality code/doing things well.
K In an Agile workflow a hierarchical organization may not be compatible
J, Yesenia has a 1.0 version of something that was created, but doesn't necessarily fit current goals, needs. Do we start Agile using existing crap, or start afresh?
- Is Agile something that can be retrofitted into an existing project that wasn't developed in that manner?
K The bigger and worse off the inherited project is from the start, the harder it is to adapt an Agile workflow into the project.
Typically these cases come in two flavors:
- someone built an existing prototype,
- or built something for production, but it's not quite what we want.
A big red flag in these circumstances is that there are no well defined boundaries, which may lead to huge scope creep.
P how do you interact with clients?
K First build your MVP, then show the client in stages every two weeks so that they can provide feedback. During the process add features, and/or address bugs.
Timelines
T How do you manage timelines?
K Kanban approach: you can collect metrics based on history of the rate in which you complete stories/features.
K Scrum approach: you can estimate number of story points over a period of time and then once you have experience you can fine-tune that estimate.
M So how does this work within a set timeline?
K having a set "triangle", (an inflexible timeline/ scope/ quality of product) will create problems when using an Agile workflow. It 'will' create issues with the ability to produce quality code. With Agile you try to focus on maximizing the quality of your code. Instead an Agile methodology says that you will get 'something' by a 'certain date', it will have 'some features'--maybe more or less than what client wants.
O How do we get the feedback loop right, fine-tune it?
K Many people get fixated around end product delivery, but this kind of thinking can be dangerous within an Agile context.
Agile in Other Contexts Beyond Software Dev
O Can you apply Agile in other contexts beyond software development?
M Relates to process of writing an essay in high school. When you're working in a small group, the ability to self assess is important.
K Even working alone without being able to interview a client/audience, you can still put yourself in the shoes of the end user. Works really well for processes that are amenable to change and amendment, but not so great for building physical, end results focused things like a skyscraper.
O Can Agile be used for community organizing?
K Absolutely. Relates experience developing software for a non-profit embarking on a campaign. Iterative thinking vs. traditional end focused process: deliver what the customer wants now, instead of focusing on delivering something that they wanted and planned 1 to 2 years ago. Try to pilot your project, frequently adapt and respond to changes.
T Related experience working with policy think tank that publishes reports. Needs to work with communities on the ground to update/fine-tune goals and release cycles for reports. Works in an Agile manner, though policy analysts wouldn't see it that way.
K works well with documentation, wikis blog, information that needs to be freqquently updated--living documentation.
Drawbacks to Agile
C What about Agile and security?
K Agile workflows create issues for the security focused, and for UI designers. UI design usually has a fixed idea of the end product. Security experts would typically emphasize that security needs to be a foundational part of a project at the beginning. This is a known point of contention between proponents of Agile and security folks. You need to understand security issues and risks from the beginning of the project--i.e. don't make security part of an Agile workflow.
Agile, Education, Implementation
O are they teaching Agile in high school?
M at Oakland Tech they aren't explicitly teaching Agile or CI (Continuous Integration), but they are imparting the concepts implicitly.
C senior year at Oakland Tech they're learning Python, junior year Java.
J what about testing, CI and its implementation? How does one wrap their head around a cultural issue, write tests and then leveraging tools to implement it?
K this is a quandary that other organizations--much larger, and more well funded--are struggling with, don't feel bad.
Tools, No Pain No Agile??
K From a tool standpoint you need a way to track changes, and version changes (i.e. Git)
- CI works hand-and-hand with Agile, if something is painful and takes too long, do it more often!
- If you commit to do something more frequently that is painful, having to do it more often will force you to address the issues, improve the process and make it more efficient.
Summary/Takeaway
K The goal is to find an Agile process that works for your team at this moment and context. Not a rigid adherence to some set process or tools. However, it's advisable to stick with one flavor of Agile first before tweaking and mixing them.