Discover and read the best of Twitter Threads about #Agile
Most recents (21)
Any imposed process, explicit (e.g. you must do standups) or implicit (e.g. you must do #agile) is likely to result in anything ranging from low performance to dysfunction. 1/
High performance comes from imposing enabling constraints (e.g. ensure we have a shippable product at all times, ensure we have a frequent feedback loop with the customer, ensure you are continuously improving), not process. 2/
Tell the team they can create whatever process they want, and that you will help remove any roadblocks. But take the constraints seriously, and make the team accountable to them. Show me the software! Show me how we're incorporating feedback! Show me how you're improving! 3/
Like most IT people I love tools. And tools are absolutely vital to #Agile, esp. #automation of #development & #delivery. But when it comes to managing teams & processes, do #tools and #Agile always mix? Maybe not…
I often hear that the Scrum Master is "responsible for the process". Is that your understanding too?
On an Agile team, using Scrum or whatever other framework or approach, shouldn't it be the Team that owns the process?
#Agile #Scrum #Team
On an Agile team, using Scrum or whatever other framework or approach, shouldn't it be the Team that owns the process?
#Agile #Scrum #Team
If so, why would the SM be the only person responsible? And if they're not, and the whole Team is involved, what is it that makes the role so special?
I'd like to hear your thoughts on that.
#Agile #Scrum #Team
I'd like to hear your thoughts on that.
#Agile #Scrum #Team
My personal view on this - a Scrum Master is supposed to be a change agent. I am there to help everyone change the system of work so that it helps meet their needs.
This goes far beyond the "process" as such, and leads to better overall results.
This goes far beyond the "process" as such, and leads to better overall results.
“How does #ux work with #agile” ?
Step 1: Read the Agile Manifesto for Software Development agilemanifesto.org
Step 2: Read the Principles behind the Agile Manifesto: agilemanifesto.org/principles.html
Step 3: For a modern twist, check out Modern Agile: modernagile.org
1/3
Step 1: Read the Agile Manifesto for Software Development agilemanifesto.org
Step 2: Read the Principles behind the Agile Manifesto: agilemanifesto.org/principles.html
Step 3: For a modern twist, check out Modern Agile: modernagile.org
1/3
...you’ll quickly notice there is no mention of Product Owners, Sprints, User Stories, Story Points, Scrum Masters, Demos, Jira, etc. And no mention of #ux, #datascience, #businessanalyts #devops etc.
There is one key thing though... 2/3
There is one key thing though... 2/3
Heard (again) that #design and #ux is somehow incompatible with #agile (which to most, means #scrum).
..that ppl can’t always jam their work into little increments
..that MVPs suck because they’re never improved
..that work can’t always be boiled down into a “ticket” 1/n
..that ppl can’t always jam their work into little increments
..that MVPs suck because they’re never improved
..that work can’t always be boiled down into a “ticket” 1/n
There are many ways to inspire a “sense of urgency” that have nothing to do with estimates/deadlines.
#agile #lean #softwaredevelopment
#agile #lean #softwaredevelopment
1. First ... giving enough context so people give a fuck. That’s a start. Otherwise, you can’t expect people to “go the extra mile”...
#agile #softwaredevelopment #ux #devops
#agile #softwaredevelopment #ux #devops
2. Let them STOP doing things that are less valuable. Nothing says “you’re free to focus and care” more than freeing people from context switching and multi-tasking.
“What would you like to stop doing, to leave time for this?”
#agile #softwaredevelopment #ux #DevOps
“What would you like to stop doing, to leave time for this?”
#agile #softwaredevelopment #ux #DevOps
I'm only halfway through Bertrand Meyer's 2014 book, "Agile! The Good, the Hype and the Ugly", but it's already proven its worth as a lucid, unrestrained appraisal of #Agile principles and methodologies. Here are a few passages that resonated with me...
"#XP's insistence that [pair programming] should be the absolute rule [...] makes little sense conceptually, as it neglects the role of programmer personality (some excellent developers like to concentrate alone and will resent having to be paired) [...]"
"Starting any significant software project (anything beyond a couple of months and a couple of developers) without taking the time to write some basic document defining core requirements is professional malpractice."
Realized I had some posts that actually make sense as a series... a little blook
1/10 Moving beyond the platitudes of outcomes vs. outputs....it is all a spectrum
hackernoon.com/beyond-outcome…
#prodmgmt #ux #design #agile #modernagile
1/10 Moving beyond the platitudes of outcomes vs. outputs....it is all a spectrum
hackernoon.com/beyond-outcome…
#prodmgmt #ux #design #agile #modernagile
2/10 Distinguising value and sequencing. Start with opportunities before getting bogged down in “LOE”
hackernoon.com/value-and-sequ…
#prodmgmt #ux #design #agile #modernagile
hackernoon.com/value-and-sequ…
#prodmgmt #ux #design #agile #modernagile
3/10 Prioritizing non-feature work and continuous improvement ... there’s value here too.
hackernoon.com/prioritizing-n…
#prodmgmt #ux #design #agile #modernagile
hackernoon.com/prioritizing-n…
#prodmgmt #ux #design #agile #modernagile
So here’s an observation and question for the #scrum community.
One of the biggest issues I’ve seen with teams new to scrum is backlog refinement. Most people do it wrong and it has huge implications on #prodmgmt. /1
One of the biggest issues I’ve seen with teams new to scrum is backlog refinement. Most people do it wrong and it has huge implications on #prodmgmt. /1
I have seen hundreds of teams treat backlog refinement as a two hour meeting where they rewrite user stories and estimate them.
While both of those are good things to do, they usually only do these two activities, instead of creating shared understanding about the work. /2
While both of those are good things to do, they usually only do these two activities, instead of creating shared understanding about the work. /2
Teams don’t spend this time story mapping, discussing in detail, or contextualizing the end state of the product together.
Actually teams new to scrum usually don’t do any of those things. /3
Actually teams new to scrum usually don’t do any of those things. /3
Almost every discussion I have that starts with “we need to go faster” ends with me asking the team to “define value”, and then do less once and work in smaller batches.
It is at this point that the reality sets in ...1/3
#agile #kanban #prodmgmt
It is at this point that the reality sets in ...1/3
#agile #kanban #prodmgmt
We were looking for a way to do something different than our competitors who were focused on SEO. We decided to tackle sending people rental listings in slack. @davemastersnyc #agileux
We discovered it was too hard to install apps on slack, so we decided to keep the thread of the idea but pivot to FB messenger. @davemastersnyc #AgileUX
We learned that apps ramp up slow but they contributed to a top line organic audience AND repeating visitors to hit our goals! @davemastersnyc #AgileUX 
Banyak banget yang nanya, ngerjain startup tu asik ya? Gw share dikit ya ilmu gw di per-startup-an selama 13 tahun terakhir. Bakal panjang ya jadi sabar-sabar ngikutinnya
Gw yakin banyak banget di sini yang ngebayangin jadi kaya Mark Zuckerberg gara-gara nonton the social network. Bikin startup tidak seindah itu, apalagi jaman sekarang, PENUH PENDERITAAN. Iya lo ga salah baca. PENUH PENDERITAAN. Tapi bukan berarti ga asik kok sob nanti lo liat
Pengalaman startup pertama gw dimulai tahun 2005. Startup pertama gw adalah sebuat software house. Jaman itu masih ngenes lah. Kenapa ngenes? Itu jamannya masih kalo lo di bidang IT harus bisa jadi superman yang bisa segala macem dan dibayar serendah mungkin
Words matter... (1/5)
Notice how words like discovery, design, delivery, build, and run often get coopted to silo / segment / divide teams/ppl
To draw imaginary lines around skills. To protect kingdoms even. To make pretty left to right diagrams.
#ux #design #agile #devops
Notice how words like discovery, design, delivery, build, and run often get coopted to silo / segment / divide teams/ppl
To draw imaginary lines around skills. To protect kingdoms even. To make pretty left to right diagrams.
#ux #design #agile #devops
Trying a new angle for teaching story slicing, one of the biggest struggles for teams attempting #agile ways of working and arguably the most important practice to understand, given we are trying to deliver value to customers in very short cycles. Read on if you are interested.
The way I see it, there are 3 levels of story slicing, each of which is beneficial and necessary to be able to deliver shippable increments consistently in 2 wks or less. I am currently calling them Capability Slicing, Functional Slicing and Implementation Slicing. What are they?
Capability Slicing is the narrowing of a broader capability* into more precise ones, each independently valuable and implementable and, by necessity, smaller in potential scope.
*The story of enabling a human being to achieve something they cannot currently achieve
*The story of enabling a human being to achieve something they cannot currently achieve
Let’s talk Definition of Done
First, with sw-prod-dev our work is never “Done”. What we’re really talking about is a temporary stopping function ...DoDFRN ... definition of done for right now (thread 1/6) #agile #prodmgmt
First, with sw-prod-dev our work is never “Done”. What we’re really talking about is a temporary stopping function ...DoDFRN ... definition of done for right now (thread 1/6) #agile #prodmgmt
Some tips for PdM working with software developers ...
#agile #prodmgmt #ux #design
1/ They’re masters of coherence in arguments, information, and statements. Expect to be called out (bluntly) on something ... and for them to be right.
#agile #prodmgmt #ux #design
1/ They’re masters of coherence in arguments, information, and statements. Expect to be called out (bluntly) on something ... and for them to be right.
2/ Don’t assume silence means a lack of interest. Sadly, introverts get chased out of the “business world”. In the swdev team world, extroverts AND introverts thrive (cool huh?). Many or my dev friends choose to chew on a thought for a long time before interjecting.
3/ Imagine a world where your every keystroke is (basically) measured, scrutinized, Jira-ed, and reviewed. And ****ing up means the whole app can go down (or worse). Compare that to your world, where you can often dismiss something with a hand wavy “that’s a learning!”
This pair of tweets neatly capture the conflicted feelings in the design community about #agile.
On the one hand, designers embrace emergence. On the other, we are hostile to agile, a system created to handle emergence. /2
On the one hand, designers embrace emergence. On the other, we are hostile to agile, a system created to handle emergence. /2
Of course, that hostility is understandable, since agile is often implemented as a "build methodology." /3
When we wrote #leanux we wanted to help product design and development teams collaborate more effectively and ultimately build better products for their customers. The overwhelming feedback from readers has been (no surprise) that they want to work this way. However...
What we didn't expect was the amount of teams out there telling us things like "my boss won't let me work this way" or "my company would never let us talk to customers." Hearing this again and again gave us the sense that there was (at least) another conversation to be had. So...
We wrote another book - #senseandrespond . That book took the conversation up a level to leaders and makes the case that to stay competitive in today's business world you have to build continuous learning loops with your customers. I believe many orgs heard this message but...
I want to talk about something I keep hearing from many places when I ask teams about their processes:
"We are different"
#agile #prodmgmt /1
"We are different"
#agile #prodmgmt /1
Whenever I coach someone or start consulting with a company, I start off with an assessment where I try to learn about the individual products and how they are run. /2
During these sessions I usually ask about how people think of strategy, do prioritization, structure their teams, and communicate. Lots of other stuff too. /3
Last week @JoshuaKerievsky, @mattbarcomb, and I had some fun poking at the Product Owner role in #Agile: . 1/n
As someone who spends every day training POs in #prodmgmt, this is close to my heart. There are so many POs who do not do real PM. 2/n
In fact, I get asked questions about the difference daily. So I wrote a blog post on it: medium.com/@melissaperri/… 3/n
